> в сабже уже существует explain ?
да:
explain select * from groupz where id=148;
NOTICE: QUERY PLAN:

Index Scan using groupz_pkey on groupz (cost=0.00..3.48 rows=1 width=69)

ifconfig

> 100 раз зарекался не ввязываться в бессмысленые споры, ах нет иногда таки "затягивает" %)

Лучший способ справиться с искушением - поддаться ему. (с) Оскар Уайлд. Так что чего уж там ;-)))) Давай отвечай ;-))))

> сли переходить с FOXPRO 2 - 2.6 ... что проще и лучше...?
GPL реализацию Clipper.:-) тут на сайте посмотри в новостях. москвичи пишут. я думаю разницы нет: дело в кол-ве мест.

> Лечится периодическим удалением/созданием индексов
это рецепт для 6.53. на самом деле лечится vacuum full

mumpster

> GPL реализацию Clipper.:-) тут на сайте посмотри в новостях. москвичи пишут.

IMHO, чего-то ты путаешь... Они же все, вроде как, поголовно из Ижевска.

> скорее всего стоит 7.2.x в этой ветке "поломали" работу с часто изменяемыми индексами. Он забывает иногда подчищать свой мусор и для таблицы в 5Mb через n-е время может держать индекс в 500Mb.

А можно ссылочку?

> ifconfig, объясните плиз, какая зависимость между скоростью выбора
> по полю от общего кол-ва полей в таблице ???

Я не ifconfig, но объяснить попробую: каждая строка занимает некоторое
место на странице диска. Если в таблице много атрибутов, то на одну
страницу влезает меньше строк. Следовательно, для того, чтобы провести
выборку, нужно вытащить больше страниц.

Ну и, конечно, 60 атрибутов в одной таблице -- это пахнет криминалом с
точки зрения схемы БД :).

BarD

> Следовательно, для того, чтобы провести выборку, нужно вытащить больше страниц.

Ну это при условии, что сервер настолько туп, что прям так подряд все данные и хранит. А еще учитывая, что половина этих полей - это int'ы, numeric'и/decimal'ы и прочие биты/байты, то вообще не понятно, чего стоит этот аргумент.

> Ну и, конечно, 60 атрибутов в одной таблице -- это пахнет криминалом с точки зрения схемы БД :).

Вот от ifconfig'a, а теперь и от тебя ( ;-)) ) народ жаждет услышать, как же именно следует поступать с таким "криминалом" ??? Учитывая, что мы имеем дело с простыми рабоче-крестьянскими серверками, которые ни про какие вложенные таблицы ничего не знают. Ась ? :-)))

> один только нормальный буфер под сортировку займёт мегов 500.

> (5000000*60*ну байтов по 7 всяко) =~2.1G min

Сдается мне что PostgreSQL делает это более грамотно все-таки. Описанное поведение больше смахивает на FireBird, та выжирала порядка полусотни метров на вышеописанном мной запросе (что было даже несколько перебором)...

PostgreSQL просто не успел бы занять столько памяти за доли секунды (тем более на винде) и освободить их...

Люди, а кто-нибудь знает, почему в комплекте нет libpq++? И почему нет бинарной совместимости с программами под 7.3.1? Они вроде как перепахали libpq.

2LamerOK
1,2,3 ну и изредка 4 нормальная форма
Если эти сочетания слов и букв ничего не говорят - в сад

Неправильно сказал я... Правильней будет "приведение к 3нф)" :)

>>Учитывая, что мы имеем дело с простыми рабоче-крестьянскими серверками, которые ни про какие вложенные таблицы ничего не знают.

А про учебники вы видать тоже знать ничего не хотите.

P.S. hint - В сети валяеться учебник В.В.Кириллова
http://khpi-iip.mipk.kharkiv.edu/library/dbms/kir1/index.htm

настоятельно рекомендую прочитать. Хотя в свое время, мне он не шибко помог(слишком поздно попался на глаза), почти ко всему я дошел сам методом проб и ошибок. Если вам по приколу наступать на грабли самостоятельно, тогда возражений больше не имею. Лично я имею достачно слабые педагогические способности и очень мало на это времени чтоб разводить лекбез в рамках ЛОР.

P.P.S. Так мы услышим таки начальника транспортного цеха (с) Жванецкий.
У смысле 60 полей признака клиента ?

кстати, начать можно прямиком отсюдова....
http://khpi-iip.mipk.kharkiv.edu/library/dbms/kir1/4-3.htm

LamerOk:
> при условии, что сервер настолько туп, что прям так подряд все данные и
> хранит.
> не понятно, чего стоит этот аргумент.
> Учитывая, что мы имеем дело с простыми рабоче-крестьянскими серверками...

Странное у вас представление о народных серверках: вложенные таблицы
делать не умеют, но вот таблицу вертикально порезать -- как с куста...

Я не знаток PostgreSQL, но нескольких минут общения с сайтом google.com и
программой Mozilla хватило, чтобы отыскать вот эту страницу:

http://developer.postgresql.org/docs/postgres/page.html

Там описан формат дисковой страницы. Кортеж хранится всем скопом.
Займемся подсчетами? Поле типа int занимает в PostgreSQL 4 байта. 60 полей
типа int занимают 240 байт. Еще хранится заголовок кортежа -- 23 байта.
Пусть вместе будет 256 для ровного счета. Размер страницы в PostgreSQL -- 8k.
Следовательно, на страницу поместится 32 кортежа. Для таблицы из 5 миллионов
записей необходимо около 150 тысяч страниц.

Время доступа к одной странице, естественно, зависит от параметров диска
и размера буфера у СУБД. Достаточно ли разумным вам кажется предположение,
что это время измеряется в единицах миллисекунд? Если да, то умножаем
150.000*1ms и получаем 150 секунд. В зависимости от объема выбранных
данных, как раз что-то вроде упоминавшихся 90 секунд и получится.

Вас удовлетворила такая стоимость аргумента?

По поводу того, как поступать с таким криминалом, несколько ссылок уже дали.
Могу подкинуть еще одну: www.citforum.ru. Сервер содержит
"Море(!) аналитической информации!" (C) Citforum
в том числе и по теории баз данных.

2mumpster
>> Лечится периодическим удалением/созданием индексов
>> это рецепт для 6.53. на самом деле лечится vacuum full
В моем случае это не помогает, а если в момент VACUUM есть нагрузка на обрабатываемую таблицу, то ситуация только ухудшается. Еще помогает REINDEX, но ее применять надо только тогда когда уверен, что OID нигде не используется.

Бедненькому с 60-ю полями в mySQL. Дай в консоли ДБ команду "desc table_name;" и получишь описание таблицы которое cup-n-paste сюда. Для PostgreSQL - "\d table_name". Ждем результатов! А то, что ты привел очень просто разбивается на группы и при необходимости для отчетов собирается в красивенькие виды (view) и никакого гемора.

Dimez

Снимись с ручника, все таблички в 3НФ.

ifconfig

> Если вам по приколу наступать на грабли самостоятельно, тогда возражений больше не имею.

Дык я это то и пытаюсь у тебя выпытать !!! Непонятно мне, какие могут быть грабли при использовании 60 полей ???

> У смысле 60 полей признака клиента ?

Ну-у.. У меня пока тока 30 набралось ;-))) Завтра на работе еще посмотрю, мож помонстровее табличку найду :-)))))

Собственно мне пока тока одна причина пришла в голову, по которой табличку имеет смысл разбивать на части - если по двум и более полям делаются частые поиски, машинка загибается, поэтому нужно делать индексы по ним, и БД не позволяет делать два независимых индекса на поля в одной табличке. Ничего другого в голову не лезет.

BarD

> Странное у вас представление о народных серверках: вложенные таблицы делать не умеют, но вот таблицу вертикально порезать -- как с куста...

Так что проще то ?? Первое или второе ??? И соответсвенно чего вероятнее будет в народных сервачках ??? (Ясень пень, что я не имел в виду мускль ;-))) )

> Кортеж хранится всем скопом.

Печально, я был о нем (о сабжике, т.е. ;-)) ) лучшего мнения...

"поэтому нужно делать индексы по ним, и БД не позволяет делать два независимых индекса на поля в одной табличке" Понятненько. Я был лучшего мнения о нем (не сабжик ;-)

>Так что проще то ?? Первое или второе ??? И соответсвенно чего вероятнее
> будет в народных сервачках ???

Я не разрабатываю народные сервачки, так что от прогнозов, что вероятнее
появится, воздержусь. Сугубо личное IMHO: сделать vertical partitioning легче
хотя бы потому, что его можно грубо сделать и самому, разбив атрибуты на
сколько нужно групп, разделив группы по таблицам и связав таблицы
FOREIGN KEY'ями. Можно сделать предположение, что именно поэтому в
народных серверах vertical partitioning и не появится (делать примитивный
вариант, в общем-то, скучно, а эмулируется легко).

> Кортеж хранится всем скопом.
> Печально, я был о нем (о сабжике, т.е. ;-)) ) лучшего мнения...

Есть предположение, что сабжик невиновен, и так будет поступать любая СУБД,
если ей явно не сказали сделать partitioning. Поскольку она не знает, *что
именно* вы собираетесь делать с таблицей (то есть, какие поля и в каких
комбинациях будут затрагивать ваши запросы), то она предпочтет свалить все
в кучу и получить более легко предсказуемое время выполнения запроса. Если
же она от балды распихает поля на разные страницы, то есть шанс, что для
выбора нескольких атрибутов одной строки ей придется трогать не одну
страницу, а N.

>>Дык я это то и пытаюсь у тебя выпытать !!! Непонятно мне, какие могут быть грабли при использовании 60 полей ???


Не, я кнечно могу и тупить в пол второго ночи, но ссылки то сыслки?? заходить пробовал?? если нет, спициально для тебя
cntr-c ->cntr-v из http://khpiiip.mipk.kharkiv.edu/library/dbms/kir1/4-3.htm

очень уважаемый человек пишет...

--------------------------------------------------
4.3. Почему проект БД может быть плохим?
Начинающий проектировщик будет использовать отношение "Питание" (рис. 4.2) в качестве завершенной БД. Действительно, зачем разбивать отношение "Питание" на несколько более мелких отношений (см. например, рис. 3.2), если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем:

1. Избыточность. Данные практически всех столбцов многократно повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт, Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов, некоторые из которых намного больше рецепта "Лобио" (см. рис. 2.3). И уж совсем плохо, что все данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо включается в меню.

2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его неизменным в других. Если поставщик кофе сообщил о своем переезде в Харбин и была обновлена строка с продуктом кофе, то у поставщика "Хуанхэ" появляется два адреса, один из которых не актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк.

3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями?

По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, "Полесье"). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)?

4. Аномалии удаления. Обратная проблема возникает при необходимости удаления всех продуктов, поставляемых данным поставщиком или всех блюд, использующих эти продукты. При таких удалениях будут утрачены сведения о таком поставщике.

Многие проблемы этого примера исчезнут, если выделить в отдельные
таблицы сведения о блюдах, рецептах, расходе блюд, продуктах и их
поставщиках, а также создать связующие таблицы "Состав" и "Поставки" (рис. 4.3).

---------------------------------------------------------

сам пример посмториш по ссылке...


P.S. Все, я устал... дальше без меня...

2 korwin:
Вы, по-моему, придираетесь :) LamerOk, по его признанию, сидит на M$ $QL,
соответственно, рецепт про "desc table_name;", скорее всего, не пройдет :)
А фразу про индексы, которые БД не позволяет делать, надо читать, наверное,
так:
"если по двум и более полям делаются частые поиски и от этого машинка
загибается, то нужно делать по ним индексы. В случае, если БД не позволяет
делать два независимых индекса на поля в одной табличке, имеет смысл разбить
табличку на две".

Хотя мне такую БД представить сложно, это даже mySQL умеет делать. Ну разве
что M$ Acce$$ :))

И еще, напоследок :)
Я предсталяю как радуетсья менеджер, которому нужно заполнить 60 полей (ну ладно, хотя-бы 30, вы ведь null писать разрешаете?) для того чтоб завести клиента который купил коробок спичек %))

>> Кортеж хранится всем скопом.

>>Печально, я был о нем (о сабжике, т.е. ;-)) ) лучшего мнения...

ALTER TABLE mytable ALTER COLUMN mycol SET STORAGE [EXTERNAL | EXTENDED ];

http://www.postgresql.org/docs/view.php?version=7.3&idoc=0&file=sql-a...

> Сдается мне что PostgreSQL делает это более грамотно все-так
я имел в виду, что при таких табличках (в 2 гига min и видимо она не одна) логично сделать некие телодвижения в сторону железа и настроек под него.

> Многие проблемы этого примера исчезнут, если выделить в отдельные
зато могут появиться "многие другие";)
просто бывают ситуации, когда у какого ключа может быть много РАЗНЫх
атрибутов, разбивать которые однако по разным табличкам смысла нет - типичный пример тут уже приводили - ОКПО/ОКОНХ. Другое дело что как правило
можно разбить все аттрибуты на 2 группы: часто используемые и их мало - в одну, редко и их много - в другую, связка - по одному и тому же ключу. такой нехитрый приём хорошо себя показывает в любой базе, включая ISAM.

Для любителей нормализации, таблиц из 3 столбцов и т. д.:
Пример не самой большой таблицы из реально функционирующей системы. Скажите что тут лишнее и я скажу почему оно так надо ;-)

1. ISN - машинный номер
2. AGRISN - FK(AGREEMENT). Указатель договора, к которому относится сумма.
3. CLASSISN - FK(DICTI,СУММА). Тип суммы (как бухгалтерской операции для автоматической генерации проводок). null-тип не определен (смешанный).
4. DATEPAY - Планируемая или фактическая дата платежа.
5. CLASSISN2 - FK(DICTI). Указатель подкласса суммы. ClassISN - его родитель
6. PARENTISN - FK(DOCSUM). ссылка на плановую суму, сквитованную с данной
7. AMOUNT - Сумма в валюте
8. SUMISN - Машинный номер инстоллмента: SEQ_DOCSUM_SUM
9. AMOUNTRUB - Сумма покрытия в локальной валюте.
10. DOCISN - FK(DOCS). Указатель документа, в который включена сумма, например, исходящий счет для начисленной премии, платежное поручение для суммы возмещения.
11. DOCISN2 - Ссылка на бухгалтерское начисление
12. SUBJISN - FK(SUBJECT). Указатель субъекта, к которому относится сумма.
13. DOCID - Внешний номер документа, в который вошла сумма. При задании DocISN устанавливается автоматически. При отсутствии DocISN может быть задан вручную, независимо от наличия документа в БД.
14. SPLITISN - FK(DOCSUM). Ссылка на исходную сумму, врезультате разбиения которой возникла данная
15. UPDATED - Дата изменения
16. UPDATEDBY - автор
17. REMAINDER - Несквитованный остаток в валюте документа
18. AMOUNTAGR - Сумма в валюте договора
19. AMOUNTUSD
20. CURRISN - FK(CURRENCY). Указатель валюты суммы.
21. GROUPISN -
22. AGRID - Номер полиса.
23. FID - Внешний машинный номер записи
24. PAYFORM - FK(DICTI.Code,accPayForm). Форма оплаты, желаемая или фактическая. Наследуется
25. STATUS - Статус суммы, поддерживается автоматически
26. DISCR- Дискриминатор типа суммы: P-плановая, F-фактическая
27. REACCISN - FK(REACC100). Указатель на начисление (заголовок 100 счета), к которому относится объект.
28. AGRCURRISN - FK(CURRENCY). Указатель валюты договора.
29. DIRECTIONFLG - Флаг направления взаиморасчетов:
30. SUBACCISN - Указатель аналитического счета
31. DEBETISN -
31. CREDITISN
32. DOCCURRISN - Указатель валюты документа.
33. AMOUNTDOC - Сумма в валюте документа,
34. DOCDATE - Дата, на которую определяется курс для пересчета в валюту документа
35. DOCRATE - Курс пересчета в валюту документа,
36. REFUNDISN - Ссылка на претензию или аддендум, по которому сделано начисление
37. DOC_TYPE - Тип документа
38. DOCADJUSTMENT - Поправка курса пересчета в валюту документа в процентах
39. INDOCISN - Ссылка на счет-калькуляцию
40. REGRESSISN - Указатель регресса, к которому относится сумма
41. KINDACCISN
42. SIGNED - - Используется для автоматического перерасчета эквивалента как дата курса, если не задана DocDate, фиксирующая курс.
43. CREATED
44. CREATEDBY
45. DEPTISN - Указатель подразделения
46. LINEISN - Указатель строки выписки в результате предварительной расшифровки
47. DATEPAYLAST - Последняя дата оплаты

Вопрос по организации таблиц

Добрый день

Вижу здесь, что специалисты попадаются, которые могут и совет дать :)

Вопрос как лучше организовать хранение данных следующего вида: В различные промежутки времени поступает для хранения различные массивы чисел INT от 1 до 10 тыс. штук в одном массиве. Необходим максимально быстрый доступ на чтение по времени (по временному полю). Периодичность поступления данных для разных массивов от 5 минут до месяца. Может быть где-нибудь есть похожие проекты.

С уважением Евгений

P.S. первая попытка (то что мне досталось в наследство) была: всё запихать в одну строчку, что естественно привело к дичайшим тормозам. Есть проблемы с поиском по временному полю при сравнении с конкретной датой - по не понятной причине индексы не используются. Используется PostgreSQL 7.1; машина PII-300 256 Мб SCSI диск.

Самое грамотное в приведенном примере, это то, что автор не подписался... И правильно!, ваш бы препод (надеюсь вы в институте каком нибудь учились?) застрелился, если бы это увидил... %)

теперь по пунткам, расшифровываю...(толко самую малость(по одному примеру из каждого пункта), трактовать весь бред надо много времени)

>>1) 1. Избыточность. Данные практически всех столбцов многократно повторяются

Если документов соднано несколько за интревал времени, курс за который не менялся, то вы будете иметь кучу повторяющихся полей. Если вы захотите менять курс задним числом, то апдайтить нужно будет несколько строк! hint -> заведи таблицу из двух полей
create table rate_table
(
current_date date
,rate number(6.2)
)

дата документа известна, всегда можно узнать курс.


>>2. Потенциальная противоречивость
в документе слишком много дат. Не исключено, что двигая даты вы можете получить изобрести "машину времени", причем без востановления истории как это получилось.

hint -> не надо лепить в одну кучу даты разных событий!

>>3. Аномалии включения.
вы не сможете в рабочем порядке составить документ, если клиент, к примеру, закхочет расплатиться валютой, которой у вас нет в БАЗЕ и курс которой вы не знаете на момент составления документа!

>>4. Аномалии удаления.
у вас слишком много FK ключей, корторые вас вообще лишают всякой возможности удаления чего либо.

>>В различные промежутки времени поступает для хранения различные массивы чисел INT от 1 до 10 тыс. штук в одном массиве.

создать две таблицы, одну для дат, другую для данных..

create table raise_date_table
(
id number
,dt date
)
alter table raise_date_table
add constraint id_pr_key primary key (ID);

/

create table data_table
(
dt number
,value_ number
)

alter table data_table
add constraint dt_fg_key foreign key (id)
references raise_date_table ();
/

впринципе, если противоречивотсть не так критична а скорост поиска важна, констрайты можно и отключить

ifconfig (*) (2003-02-13 10:29:50.861)

Добрый день

Спасибо за реакцию.

Так, собственно говоря, и планируется сделать, но опять же остаются две проблемы:

а) При работе с временным полем при выборке типа

[временное поле]>`1 Jan 2003`

индексы не используются - по крайней мере так говорит explain.

б) очень большое число столбцов для таблицы с данными (например, постгрес держит до 1600 при необходимости в 10 тыс) для этого приходится заводить поле смещения для разбиения длинных строк на более мелкие. Опытным путём выяснено, что оптимальный размер таблицы не более 100 столбцов. С увеличением числа столбцов возникают проблемы.

Основная проблема в том, что не понятно по какой причине возникают а) и б) :(

С уважением Евгений

Добавлю свои 2 копейки в защиту "60 полей в таблице".

Вы видели банковскую платежку, налоговую справку, анкету отдела кадров? Только для паспортных данных клиента нужно 5 полей - тип документа, серия, номер, кем и когда выдан. Даже если вы используете справочники для хранения, например, названий улиц, всё равно должно быть поле для ссылки на справочник. В каждой из таких форм никак не меньше 60 полей, даже если они хранятся в нескольких таблицах, для печати такой формы нужно вытащить их все.

Предлагаемый способ вертикального разбиения таблиц - не панацея, он ускоряет выполнение определенного вида запросов ценой усложнения и "утяжеления" всех других операций - добавления, редактирования, необходимости объединения таблиц при выборке из 2 "подтаблиц". Для сложных запросов ещё надо посмотреть, что меньшее зло - JOIN 3-4 "широких" или 6-8 "узких" таблиц.

Так что его нельзя считать универсальным и применимым для всех и всегда.

2Евгений. По поводу не использования индексов при работе с датами. Посмотрите postgresl.conf там можно указать принудительное использование индексов.

> Вы видели банковскую платежку, налоговую справку, анкету отдела
> кадров? Только для паспортных данных клиента нужно 5 полей - тип
> документа, серия, номер, кем и когда выдан. Даже если вы используете
> справочники для хранения, например, названий улиц, всё равно должно
> быть поле для ссылки на справочник. В каждой из таких форм никак не
> меньше 60 полей, даже если они хранятся в нескольких таблицах, для
> печати такой формы нужно вытащить их все.
Сколько не объясняй, а все без толку. Книжки хоть почитайте.

2Evgueni:

Вы храните массив в строке!? Или хотите создать для каждого числа отдельное поле??? Это риторические вопросы, теперь по существу.

Если: - INT - это числа от -32768(0) до +32767(65535) - в массиве нет повторяющихся чисел - порядок чисел в массиве не важен то лучший выход - битовый массив (первоисточник - книга "Жемчужины программирования") - строка 8Кб , в которой каждый бит - флаг, представляющий наличие этого числа. Этот подход работает и если вам нужно что-то делать с каждым числом и если нужно только узнать его наличие в массиве.

2Евгений. Как вариант можно дату в ДБ хранить в виде секунд или милисекунд (что вам удобнее) тогда для этого поля надо будет сделать тип int8 и индекс легко будет работать с > и <. Единственное требуются доп. телодвижения в клиенте по преобразованию дат в секунды (если Java, то тут проблем не возникает. У Perl, PHP тоже есть такие функции).

2Korwin

Да читал, читал я книжки. И про нормальные формы, и про проектирование БД. Кажется, самая "нормальная" форма - это 5 НФ? Там, где в каждой таблице только первичный ключ и 1(!) атрибут. Только почему-то ей никто не пользуется на практике. Вообще, проектирование БД всегда компромисс, это как в механике правило рычага - в чем-то выигрываешь, в чем-то проигрываешь, и при добавлении в механизм каждой шестеренки КПД падает.

Я имею счастье сопровождать такую БД, где клиенты, счета и проводки все разбиты на 2 таблицы, так что знаю об этом не по наслышке. Что хранить 100-200 полей в одной таблице, что в 2 - без разницы. Плюсов я не вижу. Только в 2-3 раза медленее проводки делаются.

Если вы приведете абсолютно все таблицы к 3НФ или 4НФ и у вас останется в какой-то таблице 100 полей, то как не крути, их придется где-то хранить, это определяется поставленной задачей, а не "изощренностью" проектировщика.

Количество полей в одной таблице не может быть критерием чего бы то ни было. Не стоит на этом основании делать глубокомысленные выводы об умственных способностях собеседников.

>Самое грамотное в приведенном примере, это то, что автор не >подписался... И правильно!, ваш бы препод (надеюсь вы в институте >каком нибудь учились?) застрелился, если бы это увидил... %)
Это Вы про мой пример с 47 полями? ;-) Юноша, я сам преподавал в одном из ведущих московсеих ВУЗов, а пример взят из уникальной разработки, с 1996 года обслуживающей предприятие с оборотом 1 млн. долл. в день (и это не торговля нефтью где такую сумму можно поиметь с 1 сделки.) Впрочем, это вообще не торговля. Разработка защищена 2 патентами на изобретение. Конечно, для Вас это не послужит серьезным доводом... Судя по тону и характеру суждений ;-)


>>1) 1. Избыточность. Данные практически всех столбцов многократно повторяются

Чушь. 1-2 места где данные повторяются вызваню необходимостью денормализации для ускорения времени выполнения запросов. У нас с системой параллельно работает около 1000 пользователей для которых компьютер - основной рабочий инструмент.

>Если документов соднано несколько за интревал времени, курс за который не менялся, то вы будете иметь кучу повторяющихся полей. Если вы захотите менять курс задним числом, то апдайтить нужно будет несколько строк! hint -> заведи таблицу из двух полей
create table rate_table
(
current_date date
,rate number(6.2)
)

Где вы храните коды валюты из которой и в которую приходится конвертировать? Слышали о спец. курсах для VIP клиентов? Знаете что курс может быть по курсу ЦБ или Financial Times и меняется несколько раз в день?

>дата документа известна, всегда можно узнать курс.
см. предыдущее замечание. И что, вы суммы потом задним числом по курсу пересчитываете? У нас несхождение платежей в 1 коп. это ЧП при сделках в десятки тысяч USD.


>>2. Потенциальная противоречивость
>в документе слишком много дат. Не исключено, что двигая даты вы >можете получить изобрести "машину времени", причем без востановления >истории как это получилось.

Естоественно на каждое изменение в базе пишется история - кто, когда, во сколько, что было - что стало и так далее. Данные не стираются никогда. Кстати, о каком документе Вы говорили? Представленная таблица просто расшивка сумм документа, которые все могут быть за разные даты, как правило в разных валютах и с разными курсами даже за одну дату. В документе же, структура которого тут не приведена тоже много дат - создания, подписания, изменения, вступления в силу, прекращения действия например

hint -> не надо лепить в одну кучу даты разных событий!
Они нужны в одном месте. Просто нужны!

>>3. Аномалии включения.
>вы не сможете в рабочем порядке составить документ, если клиент, к >примеру, закхочет расплатиться валютой, которой у вас нет в БАЗЕ и >курс которой вы не знаете на момент составления документа!

А у Вас такие платежи возможны? Чудеса. hint подпишитесь на рассылку центробанка и введите понятие кросскурса.



>>4. Аномалии удаления.
>у вас слишком много FK ключей, корторые вас вообще лишают всякой >возможности удаления чего либо.
Ничто и никогда не удаляется. Это просто закон для серьезных программ. Часто приходится поднимать данные с 96 года со всей историей изменений - буквально каждый чих.

Вобщем, не знаю чего и где Вы разрабатываете, но с действительно большими системами вы похоже не работали. hint-> работайте над собой. и будьте более спокойны при выражении своего не обязательно правильного (но и не обязательно неправильного) мнения.

С уважением, Сергей Маслов, инж.-программист 1 кат. управления проектирования и разработки компании "Ингосстрах"

BarD

> А фразу про индексы, которые БД не позволяет делать, надо читать, наверное, так:

Именно ! Спасибо за понимание ;-))) Не думал, что кто-то сможет понять ее иначе ;-)))

ifcofig

> Не, я кнечно могу и тупить в пол второго ночи, но ссылки то сыслки?? заходить пробовал?? если нет, спициально для тебя ...

Нет, я конечно придурок, но не до такой же степени ?!! Ты мне собираешься рассказать о том, что такое отношения и с чем их едят ??? Или про ссылочную целостность ?? ;-))) Я же русским языком оговорил , что в табличке присутствуют атрибуты только одной сущности. В ответ ты начинаешь мне доказывать, что такой таблички не может быть без нарушения той или иной НФ, просто потому, что этого не может быть никогда. ;-))) Ладно, в общем стороны поняли друг друга и разошлись как в море корабли ;-))) На сем и предлагаю завершить :-)))

Ладно, раз количество участников возрастает, предлагаю продолжить ;-))

> Только для паспортных данных клиента нужно 5 полей - тип документа, серия, номер, кем и когда выдан.

А теперь я добавлю копейку в копилку "противников 60 полей" ;-))) На самом деле эти данные нужно разбивать на поля только в том случае, когда по какой-либо их части делается поиск. Если же они нужны только для единоразового ввода и последующего вывода, поиск по какой-либо их части никогда не делается, то их было бы логичнее запихать в одну строку.

2LamerOk Насколько я помню, это противоречит определению 1НФ - атомарности (неделимости) данных в полях таблиц. Разбиение паспортных данных и адресов на поля - не прихоть, а необходимость.

Я привел конкретный пример - налоговую справку. Есть соответствующий приказ МНС с приложениями где расписано какие поля и в каком виде выводить. Раньше они (пасп.данные и адрес) так и хранились - одной строкой. Но их пришлось перевести в формат с разбивкой по полям. И таких полей для каждого клиента - 2 десятка.

Блин, скока тут ламаков-то... Один трезвый мужчина - anonymous (*) (2003-02-13 13:10:45.009) А ifconfig - то в натуре чайник. Книжок начитался, сделал логистику овощного киоска - и ну гнуть пальцы...

Вообще-то спор становится беспредметным. Бессмысленно спорить, 60 полей для таблицы - это много или мало. Каждый судит со своей колокольни. Любая БД это модель. Её размер и сложность зависят от задач, которые она должна решать.

> ALTER TABLE mytable ALTER COLUMN mycol
> SET STORAGE [EXTERNAL | EXTENDED ];

Спасибо. Надеюсь, поклонникам сабжика будет полезно. Только после
диагонального прочтения документации сложилось ощущение, что это не совсем то,
что нужно. Во-первых, черт его знает, что это за supplementary table такая. Будет
ли она для каждого атрибута своя? Как можно сказать СУБД, что вот эту группу
атрибутов надо запихать в одну supplementary table, а вот эту в другую (в
СУБД, принадлежащих буржуйскому классу, можно в операторе CREATE TABLE
крикнуть слово PARTITION, указав атрибуты, помещаемые в отдельную
partition)? Во-вторых, они сами пишут, что
<цитата>
PLAIN must be used for fixed-length values such as INTEGER...
</цитата>

В общем, кажется, что EXTERNAL и EXTENDED -- удел атрибутов типа BLOB и
CLOB, а мы тут треплемся о таблицах, содержащих 60 полей типа INTEGER...

> Насколько я помню, это противоречит определению 1НФ - атомарности (неделимости) данных в полях таблиц.

Все зависит от того, будут ли эти данные делить. Если не будут, то и нарушения никакого нет. Кстати о книгах и 1НФ, сколько книжек не видел - все остальные НФ объясняются единообразно, а 1НФ все толкуют по разному :-))))

> Есть соответствующий приказ МНС с приложениями где расписано какие поля и в каком виде выводить.

Ну тогда и вопросов нет. Я не в плане наезда или еще чего говорил, я просто поделился мыслью... :-))))

> Блин, скока тут ламаков-то...
> Один трезвый мужчина - anonymous (*) (2003-02-13 13:10:45.009)

Нет, двое. Вы себя забыли сосчитать.

Читаю и охреневаю, от Вас Lamerok...


>А теперь я добавлю копейку в копилку "противников 60 полей" ;-))) На >самом деле эти данные нужно разбивать на поля только в том случае, >когда по какой-либо их части делается поиск. Если же они нужны >только для единоразового ввода и последующего вывода, поиск по какой->либо их части никогда не делается, то их было бы логичнее запихать в >одну строку.

А через недельку, приходит к Вам заказчик и говорит: а теперь мне нужен поиск по этому полю. В таблице 5 миллионов записей. Ваши действия: послать заказчика ? ручками начать резать 5 млн строк ?
написать супер пупер AI по разрезанию который наглючит еще больше проблем ?

Доводы про окучивание овощного ларька и опыта разработки больших систем попахивают правдой.

В догонку, в таблицах баз налоговой инспекции и 120 полей встречалось и ничего, бегает все.

> А через недельку, приходит к Вам заказчик и говорит: а теперь мне нужен поиск по этому полю.

Мож я чего-то не по русски пишу ?.. Я же сказал РУССКИМ (по крайней мере по моему скромному разумению) языком, что если ТРЕБУЕТСЯ поиск по отдельной части данных (хм, хотел бы я посмотреть на того заказчика, которому нужен поиск только по серии паспорта ;-))) ) или хотя бы вывод части этих данных, то конечно надо делать отдельные поля.

anonymous (*) (2003-02-13 12:00:00.168)

Добрый день

Книжку читал - хорошая, а вот совет не очень :(, так как для каждого числа необходимо своё поле (каждый столбец соответствует своему каналу электронники - часто возникает желание посмотреть какой-то конкретный канал) и соответственно число могут быть повторяющимися - никто им этого запретить не может.

С уважением Евгений