Хранение справочников в одной таблице. Предлагаю обсудить идею.

← →
AndrewK (2005-09-05 17:23) [0]

Доброго времени суток!

Есть идея некоторые справочники, хранить в унифицированном виде.
В таком виде предлагается хранить всякие классификаторы, перечислимые справочники и т.д. Например, справочник цветов, рабочих мест, географии, профессий, складов и т.д.

Для этого создается такая структура:

Create table [CollectionType] ( [ID] Integer Identity NOT NULL, [Parent_ID] Integer NULL, [Name] Varchar(50) NOT NULL, [Alias] Varchar(50) NULL, [IsGroup] Tinyint Default 0 NOT NULL, Primary Key ([ID]) ) go Create table [Collection] ( [ID] Integer Identity NOT NULL, [CollectionType_ID] Integer NOT NULL, [Value] Varchar(250) NULL, Primary Key ([ID]) ) go Create table [ParamPlacement] ( [Collection_ID] Integer NOT NULL, [Note] Varchar(250) NULL, Primary Key ([Collection_ID]) ) go Create table [ParamWorkPlace] ( [Collection_ID] Integer NOT NULL, [Code] Varchar(10) NULL, [Status] Tinyint NULL, Primary Key ([Collection_ID]) ) go Create Index [ixCollectionType] ON [Collection] ([CollectionType_ID] ) go Alter table [CollectionType] add foreign key([Parent_ID]) references [CollectionType] ([ID]) on update no action on delete no action go Alter table [Collection] add foreign key([CollectionType_ID]) references [CollectionType] ([ID]) on update no action on delete no action go Alter table [ParamPlacement] add foreign key([Collection_ID]) references [Collection] ([ID]) on update no action on delete no action go Alter table [ParamWorkPlace] add foreign key([Collection_ID]) references [Collection] ([ID]) on update no action on delete no action go

В таблице CollectionType вводим типы справочников, например, "Склады", "Цвета", "Профессии". Также там можно группировать справочники для удобства.
В таблице Collection храняться сами значения справочников (для теста там указан тип varchar, но можно поставить sql_variant)
Если справочник должен содержать не только списоные данные, а еще и дополнительные, например комментарий, персональный код или еще что-нибудь, то создается дополнительная таблица с префиксом Param, связанная с соответствующим ID таблицы Collection. Для контроля целостности можно навешать триггеров, но сейчас это опустим.

Что мы получим хорошего:
1. Единая философия создания справочников в системе.
2. Можем создать конструктор, который облегчит создание новых справочников
3. Можем создать почти универсальный модуль для управления справочниками (универсальный - если конструктор форм вынести за пределы приложения, но это уже украшательства)
4. Уменьшим число таблиц
5. Хранить все будем в одном месте, не предется рыться среди сотни таблиц в поисках одной маленькой, но очень нужной.
6. Можем навесить на таблицы сервисы контроля, логирования и т.д., которые не надо будет копировать, если будет нужен новый справочник.
7. Что-то еще есть хорошее, интуиция подсказывает....

Что получим плохого:
1. Наверное получим тормозов на больших объемах
2. Может получим проблемы с работой большого числа пользователей
3. Можем получить путаницу в данных, если начнем бездумно работать с таблицами
4. Может еще чего-нибудь получим нехорошего, не придумал пока.

Идея, думаю, не нова. Оцените, пожалуйста, ее на качество, хорошая или нет, где, по вашему, могут быть проблемы и стоит ли заморачиваться по разработке в данном направлении или лучше все по старому: один справочник - одна таблица + три-пять процедур.

С уважением.

← →
Prohodil Mimo © (2005-09-05 17:35) [1]

> Что мы получим хорошего

1. A kazhdaja tablica po otdel"nosti - ne jedinaja filosofija?
2. nikakih problem i s otdel"nimi tablicami.
3. ne problema i dlja otdel"nih tablic. jest" rabochij variant, strok ne boleje 10.
4. a ono tebe meshajet? vsjo-ravno vsjo v odnom faile hranitsja.
5. sejchas kucha tablic, a budet gora strok.
vot voz"mjom neskol"ko meshkov, v odnom goroh, v dugom fasol", v tret"jem bobi - ne udobnjak... meshkov mnogo. Ssipem ih v odin, i ne nado potom nuzhnij meshok iskat". Udobno! :o)

> Что получим плохого:

Jesli net nichego horoshego, to ne stoit perechisljat" plohoje :o)

← →
Nikolay M. © (2005-09-05 17:38) [2]

Идея, действительно, не нова. +- расписал правильно. Я лично не сторонник такого.
Имхо, имеет смысл только в системах, предусматривающих руление справочниками самими пользователями (например, если программа не коробочная, а заказчик и исполнитель территориально далеко "не рядом").

← →
Reindeer Moss Eater © (2005-09-05 17:42) [3]

Все перечисленные плюсы присутствуют и в схемах где по одной таблице на каждый справочник.
То есть все это и там возможно.

← →
Ega23 © (2005-09-05 17:47) [4]

Сначала несколько "ремарок"
1. [Value] Varchar(250) NULL, Почему 250? Тогда уж 255...
2. [ID] Integer Identity NOT NULL, Использование ключевых слов для названий таблиц-столбцов-переменных КРАЙНЕ не рекомендуется.

Это из того, что первым в глаза бросилось.
Теперь о самой идее.
1. Как быть с индексами? единый индекс на Value? А это геморно...
2. Использование identity делает невозможным заливку базы единым скриптом. Точнее, залить-то возможно, только резко возрастает сложность скрипта.
3. Ну и самое главное: ИМХО, на приведении Value к конкретным типам данных сожрётся дофига времени. Для серьёзных проектов - не годится.
Да, ещё забыл: грохнуть таблицу - гораздо сложнее, чем грохнуть её содержимое. А в предлагаемом варианте содержимое и является таблицей. Т.е. удаление записи в CollectionTypes равносильно удалению справочной таблицы в обычном её понимании.

Хотя некие похожие идеи приходилось реализовывать.

← →
AndrewK (2005-09-05 17:48) [5]

> 1. A kazhdaja tablica po otdel"nosti - ne jedinaja filosofija?

Единая, кто же спорит. Так я предлагаю такую оценить.

4. a ono tebe meshajet? vsjo-ravno vsjo v odnom faile hranitsja.

Когда система в стадии разработки - довольно сильно мешает.

5. sejchas kucha tablic, a budet gora strok.

Строки я могу фильтровать, сортировать, править при желании, а с таблицами это несколько сложнее.

vot voz"mjom neskol"ko meshkov, v odnom goroh, v dugom fasol", v tret"jem bobi - ne udobnjak... meshkov mnogo. Ssipem ih v odin, i ne nado potom nuzhnij meshok iskat". Udobno! :o)

Тогда уж добавим в этот мешок для каждого объекта (боб, горох, фасоль) признак "Тип" (см. CollectionType_ID таблицы Collection) и можем говорить в мешок: "А ну бобы, все наружу..." и у нас все бобы высыпались из мешка. Удобняк! :)

> Jesli net nichego horoshego, to ne stoit perechisljat" plohoje :o)
А все-таки очень интересно...

← →
Prohodil Mimo © (2005-09-05 17:57) [6]

Da ladno, ne podumajte chto ja zlobno :o)
et toka tak kazhetsja.

Kto kak pitajetsja sebe oblegchit" zhizn" pri razrabotke programm.

Ja dvigajus" v tom napravlenii, chto bi programma sama opredeljala chto pered nej za tablica.

Pitajus" razrabotat" nekij shablon, a programma po nemu opredelit hto delat".
jesli udastsja, to mozhno budet odnoj i toj zhe programme podsunut" sovershenno raznije bazi v kotorih v odnoj iz tablic nahoditsja kratkoje opisanije strukturi. A programma uzhe adaptirujetsja.
mozhet takoje uzhe i jest", no ja hochu sam, svoimi rukami.

← →
MOA © (2005-09-05 17:57) [7]

Самый большой минус в такой схеме, ПМСМ - это то, что ссылочная целостность здесь только для красоты, и не несёт никакой смысловой нагрузки - в том смысле, что в качестве атрибута "сорт рыбы" вполне можно получить значение "ВАЗ2101", или "слесарь-сборщик" ;).
Т.е. модель "сущность-связь" не поддерживается, либо, если поддерживается - ценой огромнейшего геморроя.

← →
Val © (2005-09-05 17:57) [8]

>AndrewK (05.09.05 17:48)
как сказал [2] Nikolay M. © (05.09.05 17:38), идея это обсуждалась неоднократно и на множество постов и в этой конференции, чем начинать заново, поищите существующие топики, мне кажется, будет продуктивнее.

← →
Shaman_ © (2005-09-05 18:02) [9]

1
[2] Имхо, имеет смысл только в системах, предусматривающих руление справочниками самими пользователями
А что мешает рулить справочниками с системой 1 справочник - 1 таблица?

2
В предложеном варианте будет сложней с разграничением прав доступа к справочникам

← →
AndrewK (2005-09-05 18:19) [10]

> Nikolay M. © (05.09.05 17:38) [2]

>Имхо, имеет смысл только в системах, предусматривающих руление >справочниками самими пользователями (например, если программа не >коробочная, а заказчик и исполнитель территориально далеко "не >рядом").

Зачем мне это понадобилось:

Допустим надо добавить справочник "Цвета". Мои действия:

1. Создаем таблицу
2. Создаем процедуры для управления таблицей
2.1 Добавить запись
2.2 Править запись
2.3 Удалить запись
2.4 Получить справочник списком
2.5 Получить информацию о записи
3. Создаем интерфейс для управления справочником
3.1 Создаем формы для ввода
3.2 Настраиваем вызовы процедур
3.3 Встраиваем редактор справочника в общую систему

В итоге мы имеем в системе +1 таблицу, +5 процедур, +1 окно исполняемого модуля.

Завтра мне необходимо добавить справочник "Профессии". И все заново.

Я согласен, что это все нетрудно, но работа, какая-то обезьянья. Пример приведен без требований логирования изменений, контроля доступа и т.д. В итоге база растет по количеству объектов, ориентироваться в них все сложнее, да и эта рутиннная работа по вводу справочников уж очень меня достает.

> Reindeer Moss Eater © (05.09.05 17:42) [3]
>Все перечисленные плюсы присутствуют и в схемах где по одной >таблице на каждый справочник.
>То есть все это и там возможно.

Я знаю, просто хотел мнение ваше услышать об идее.

> Ega23 © (05.09.05 17:47) [4]

> Сначала несколько "ремарок"
> 1. [Value] Varchar(250) NULL, Почему 250? Тогда уж 255...

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

> 2. [ID] Integer Identity NOT NULL, Использование ключевых слов для названий таблиц-столбцов-переменных КРАЙНЕ не рекомендуется.

А так удобно... :(

Это из того, что первым в глаза бросилось.
Теперь о самой идее.
1. Как быть с индексами? единый индекс на Value? А это геморно...

А зачем индекс на значение перечислимого типа. Индекс настроен на тип значения и на его уникальный код. Все остальное - это для отчетов :)

2. Использование identity делает невозможным заливку базы единым скриптом. Точнее, залить-то возможно, только резко возрастает сложность скрипта.

А насколько это требуется? Identity можно снять, но в таком случае надо самому следить за уникальным кодом.

3. Ну и самое главное: ИМХО, на приведении Value к конкретным типам данных сожрётся дофига времени. Для серьёзных проектов - не годится.

Можно несколько обойти проблему, если вместо одного поля ввести несколько разных типов и поле с номером, откуда брать данные. Value в этом случае будет вычисляемым по case. Можно еще что-нибудь придумать. Но опять же насколько это критично?

Да, ещё забыл: грохнуть таблицу - гораздо сложнее, чем грохнуть её содержимое. А в предлагаемом варианте содержимое и является таблицей. Т.е. удаление записи в CollectionTypes равносильно удалению справочной таблицы в обычном её понимании.

Так и есть. Удалил запись - исчез справочник, добавил - появился.

А насчет грохнуть записи: Как же их просто так грохнуть? Там же связь по ключу. Пока записи в подчиненной таблице есть ничего удалить нельзя. А если ничего нет, то как просто удалить, так просто и заново создать, благо полей немного.

Хотя некие похожие идеи приходилось реализовывать.

Интересно. Если не коммерческая тайна, то какие?

← →
Ega23 © (2005-09-05 18:28) [11]

Интересно. Если не коммерческая тайна, то какие?

Ну, как раз нечто похожее ваяю. Смысл следующий - есть куча разных таблиц. Нужно организовать возможность доступа к данным, как в ООП. С возможностью использования as и is.
Если очень сильно интересно, можешь стукнуться на egorov@dedal.dubna.ru
Просто писать больно много получается...

← →
AndrewK (2005-09-05 18:33) [12]

> MOA © (05.09.05 17:57) [7]

> Самый большой минус в такой схеме, ПМСМ - это то, что ссылочная > целостность здесь только для красоты, и не несёт никакой смысловой нагрузки - в том смысле, что в качестве атрибута "сорт рыбы" вполне можно получить значение "ВАЗ2101", или "слесарь-сборщик" ;).
> Т.е. модель "сущность-связь" не поддерживается, либо, если поддерживается - ценой огромнейшего геморроя.

Если эту связь создать в том виде как она должна быть, например при помощи триггеров или при помощи проверок при вводе записей на клиенте, то других мнений против схемы нет?

> Val © (05.09.05 17:57) [8]

> как сказал [2] Nikolay M. © (05.09.05 17:38), идея это обсуждалась неоднократно и на множество постов и в этой конференции, чем начинать заново, поищите существующие топики, мне кажется, будет продуктивнее.

Пробовал. Может Интернет отвернулся от меня. :) Пожалуйста, поделитесь ссылочками.

> Shaman_ © (05.09.05 18:02) [9]

> В предложеном варианте будет сложней с разграничением прав доступа к справочникам

Если на уровне сервера, то действительно сложнее, но не так уж сильно. А если на стороне клиента, то наоборот, все гораздо проще.

← →
Sergey_Masloff (2005-09-05 22:15) [13]

Чем не устраивает ВСЕ справочники в одной "деревянной" таблице? Естественно, c "расширениями". То есть в общем дереве общий набор атрибутов если его совсем уж не хватает - поддерево расширяется доп. таблицей.
Использую эту схему уже давно, а последние года три использую вообще только ее. Никаких граблей пока не наблюдаю.

← →
Prohodil Mimo © (2005-09-06 00:10) [14]

AndrewK (05.09.05 18:19) [10]
В итоге мы имеем в системе +1 таблицу, +5 процедур, +1 окно исполняемого модуля.

Spravochnikov s pol sotni, a v sisteme tol"ko odno okno dlja otobrazhenija spiska tekushego spravochnika i tol"ko odno okno dlja otobrazhenija vseh polej tekushej zapisi. Pri otkritii okna so spiskom tol"ko ukazivaju kakoj DataSource otobrazhat", ostal"noje vsjo samo opredeljajetsja.
Teksta upravlenija okolo 10 strok.
V tablicah raznije kol-va polej i raznih tipov.
Esli nado dobavit" novij spravochnik :
sozdaju tablicu, kidaju v datamodul DataSet i Datasource, v programme dobavljaju knopku ili menu chto-bi pokazivat" spravochnik i vsjo. Nikakih novih procedur i form.

← →
Prohodil Mimo © (2005-09-06 00:14) [15]

mozhno pojti i dal"she:
v imena vseh spravochnikov dobavit" kombinaciju simvolov (naprimer : profes_kl, grupa_kl i t.p.)
pri starte programmi perebirat" vse tablici i vijavljat" spravochniki po imenam, dinamicheski generit" menju ili jesho chego tam. togda dobavlenije spravochnika svoditsja tol"ko k "create table ..."

← →
Ильш © (2005-09-06 06:29) [16]

и все пишут ИМХО да ИМХО
молодцы!
потому как те кто не реализовывал такого рода систему подходят как теоретики... а теоретизировать можно до бесконечности
такой подход я ИМХО :)) полностью поддерживаю!!!
мы у себя разворачивали подобную систему, и она отлично работала и никаких тормозов (которые предрекают теоретики)
правда говорю работала, потому как сейчас на смену ей грядет внедрение ERP системы... но это совсем дургая песня

делайте!!! и никого не слушайте!!!

← →
Sergey13 © (2005-09-06 09:46) [17]

2AndrewK (05.09.05 17:23)
Как ты будешь идентифицировать справочники для написания запросов.
Допустим в CollectionType есть типы справочников
1- "Склады"
2- "Цвета"
3- "Профессии"
Как ты узнаешь, что Склады - это 1, если сам CollectionType формируется произвольно. По наименованию? Или это будет жесткая, не редактируемая пользователем, таблица? А если справочники перезальют? Проблемы могут возникнуть.
Вместо нескольких маленьких таблиц будет одна приличная, к которой будет очень частое обращение. Иногда несколько обращений в одном запросе. Ковыряться в большой сложнее чем в маленькой.

ИМХО, идея неплохая, но реализация достаточно сложна.

← →
MOA © (2005-09-06 10:12) [18]

ПМСМ, такой подход - есть попытка упростить "начальное" программирование (т.е. при старте проекта) за счёт значительного усложнения последующего программирования.
Нетривиальные запросы к такой структуре и поддержка её целостности (бизнес-правил) ПМСМ, при развитии проекта станут сущим кошмаром (например, составить запрос не зная содержимого таблицы невозможно).
Т.о., чтобы не делать программулю в ~5000 строк - мы ликвидируем поддержку целостности и бизнес-правил на уровне СУБД + значительно усложняем (увеличиваем к-во строк кода и логику) приложения.
В таком подходе мы пользуемся механизмом СУБД только для хранения данных и разруливания блокировок (причём, это разруливание - уж как получится, механизмы индексации и блокировок БД ставим "в пиковое положение"). Остальными 80% механизмов мы не пользуемся.

← →
AndrewK (2005-09-06 16:36) [19]

> Sergey_Masloff

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

> Ильш

Спасибо. Буду делать.

> Prohodil Mimo

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

> mozhno pojti i dal"she:
> v imena vseh spravochnikov dobavit" kombinaciju simvolov (naprimer : profes_kl, grupa_kl i t.p.)

Тогда уж лучше, ИМХО, создать структуру в базе данных в которой будет описана структура таблиц, вид меню и т.д. Тогда сканировать ничего не надо и интерфейс можно красивее сделать.

До сего момента так и делал.

> Sergey13 © (06.09.05 09:46) [17]

> Как ты будешь идентифицировать справочники для написания запросов.
> Допустим в CollectionType есть типы справочников
> 1- "Склады"
> 2- "Цвета"
> 3- "Профессии"
> Как ты узнаешь, что Склады - это 1, если сам CollectionType формируется произвольно. По наименованию? Или это будет жесткая, не редактируемая пользователем, таблица?

Пользователь не будет сам менять структуру справочников. Он может только управлять содержимым. Для каждого справочника добавляется Alias, посредством которого можно работать с ним. Например, справочник "Цвета", алиас - "Color", доступны процедуры "ColorItemAdd", "ColorItemEdit", "ColorItemDelete", "ColorListGet", "ColorItemGet". Зная алиас можно сконструировать все процедуры, которые работают с данным справочником.

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

Вот это, пожалуй, самое большое мое опасение. Поэтому и думаю, использовать данную структуру только для не критичных справочников. Критичные думаю делать отдельно.

> MOA © (06.09.05 10:12) [18]

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

Я понимаю цель как раз в дальнейшем упрощении работы со справочниками, а не в усложнении. Где я ошибаюсь?

> Нетривиальные запросы к такой структуре и поддержка её целостности (бизнес-правил) ПМСМ, при развитии проекта станут сущим кошмаром (например, составить запрос не зная содержимого таблицы невозможно).

Почему не зная?

select * from Collection where CollectionType_ID = 1 -- Например 1 - это "Цвета"

Можно для удобства в функцию завернуть или в представление.

> Т.о., чтобы не делать программулю в ~5000 строк - мы ликвидируем поддержку целостности и бизнес-правил на уровне СУБД + значительно усложняем (увеличиваем к-во строк кода и логику) приложения.

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

> В таком подходе мы пользуемся механизмом СУБД только для хранения данных и разруливания блокировок (причём, это разруливание - уж как получится, механизмы индексации и блокировок БД ставим "в пиковое положение"). Остальными 80% механизмов мы не пользуемся.

Можно подробнее? Если можно, то с примерами.

← →
Sergey13 © (2005-09-06 16:42) [20]

>Для каждого справочника добавляется Alias, посредством которого можно работать с ним. Например, справочник "Цвета", алиас - "Color",
Что за алиас? Name из CollectionType? А если придет грамотей и исправит американский "Color" на английский "Colour"? Где будут твои запросы?

← →
Sergey13 © (2005-09-06 16:43) [21]

Сори
>Name из CollectionType?
читать
Alias из CollectionType?

← →
AndrewK (2005-09-06 16:58) [22]

> Sergey13 © (06.09.05 16:42) [20]

> Что за алиас? Name из CollectionType?

Alias - это системное имя справочника. Задается один раз при его создании. В примере я его не стал указывать, так как не считаю это поле таким уж значимым. Как вариант можно распечатать ID справочников и ими пользоваться. Просто с Alias более читабельно. Name - это человеко читаемое название справочника. Так как сам справочник унифицирован, то и редактор тоже один. Name - это чтобы пользователь знал, что он знал, что правит.

> А если придет грамотей и исправит американский "Color" на английский "Colour"? Где будут твои запросы?

Процедуры, настроенные на справочник Color перестанут работать. То же случиться, если я переименую таблицу в Enterprice Manager.

← →
AndrewK (2005-09-06 16:59) [23]

> Name - это чтобы пользователь знал, что он знал, что правит.

Эк я завернул... :-o
Правильно так:

Name - это чтобы пользователь знал, что правит.

← →
Sergey_Masloff (2005-09-06 17:07) [24]

AndrewK (06.09.05 16:36) [19]
>А какое количество записей в справочниках храниться у Вас
Порядка 20 млн.
Система большая пользователей очень много. Тормозов нет.
В отдельные (они не отдельные на самом деле) таблицы выносятся только те что не влазят по ширине в общую шапку. Но и для них шапки в этой единой таблице есть. То есть любую справочную информацию вытаскиваем ВСЕГДА из одной таблицы но иногда приходится джойнить ее с расширением. Хотя даже при наличии расширения джойн часто не нужен.

← →
AndrewK (2005-09-06 17:19) [25]

> Sergey_Masloff (06.09.05 17:07) [24]

> >А какое количество записей в справочниках храниться у Вас
> Порядка 20 млн.
> Система большая пользователей очень много. Тормозов нет.

По-моему, это более чем достаточно для уничтожения всех сомнений о тормозах.

> В отдельные (они не отдельные на самом деле) таблицы выносятся только те что не влазят по ширине в общую шапку. Но и для них шапки в этой единой таблице есть. То есть любую справочную информацию вытаскиваем ВСЕГДА из одной таблицы но иногда приходится джойнить ее с расширением. Хотя даже при наличии расширения джойн часто не нужен.

Вот это я и хотел услышать. Прямо бальзам на душу. :)

← →
Alexander Panov © (2005-09-06 18:03) [26]

Расширение(программирование) такой системы - полная ж.
Достаточно посмотреть, как организовано в Диасофт5НТ, чтобы навсегда забыть такой подход.

← →
Alexander Panov © (2005-09-06 18:04) [27]

Сопровождение и добавление функционала - еще более огромная.

← →
Alexander Panov © (2005-09-06 18:06) [28]

AndrewK (06.09.05 17:19) [25]
Прямо бальзам на душу. :)

Как раз после того, как система поработает, обрастет доп. функциями.
Через месяц-два после того, как позанимаешься другими делами, составление SQL-запроса для получения данных будет представлять собой весьма нетривиальную задачу.

← →
Sergey_Masloff (2005-09-06 18:07) [29]

← →
Sergey_Masloff (2005-09-06 18:12) [30]

Alexander Panov © (06.09.05 18:06) [28]
Варум????
Могу уверить - ничего подобного. Более того, имхо НАМНОГО проще так как джойнишь всегда с одной и той же таблицей. То есть никогда не вспоминаешь - а валюты это у меня какая таблица? А типы платежей? А контрагенты? А счета? ;-) И попробуй расскажи это новичку.
А тут все самодокументировано - человек смотрит одну таблицу и в ней находит все. Так что надумано это все. С любым подходом можно сделать г а можно конфетку и если конкретно у тебя не получилось конфетки таким способом не надо говорить что это невозможно (обратное тоже верно). То есть я уверен что в системе 1 справочник-1 таблица тоже можно сделать нормально, более того я делал когда-то и с автогенерацией форм для редактирования и просмотра и так далее. Но потом решил что удобнее не так (для меня). Подход вроде оправдывается ;-)

Sergey_Masloff (06.09.05 18:12) [30]
А тут все самодокументировано - человек смотрит одну таблицу и в ней находит все.

Хорошо, если это одна таблица. А если в ней находятся классификаторы к 20-ти справочникам?

Допустим, есть таблица проводок, документов, клиентов.

В этих таблицах находятся исключительно ссылки на эту громадную таблицу в числовом виде.

Пусть будет 20 видов документов, 5 тысяч клиентов, и 1000000 различных классификаторов в справочной таблице.

Есть задание - найти документы клиента "Рога и копыта", и получить полностью всю информацию по документу.

Предложи путь решения задачи?

Sergey_Masloff (06.09.05 18:12) [30]
То есть никогда не вспоминаешь - а валюты это у меня какая таблица? А типы платежей? А контрагенты? А счета? ;-)

А как ты запоминаешь идентификатор справочника валюты? В голове держишь?

То же касается и остальных.
Для составления олюбого запроса тебе нужно сначала вспомнить(найти) идентификаторы, классификаторы нужных тебе понятий, толтько потом увязывать их в запросе.

Если постоянно не заниматься разработкой, то сопровождение с нуля(вместе с изучением) подобной задачи - полный мрак.

← →
Sergey_Masloff (2005-09-06 18:29) [34]

Alexander Panov © (06.09.05 18:19) [31]
>А если в ней находятся классификаторы к 20-ти справочникам?
Да хоть к 20 тысячам (как у нас и есть)

Документы - это не справочная таблица.
Твоя задача надуманная - в ней нет никакого подвоха. При чем тут 20 видов документов? Хоть 120

select d.id, c.code currcode, cl.shortname doctype, ... xN.shortname someother
from docs d, dicti c, dicti cl, dicti x2, ... dicti xN
where d.clientidn = :id
and d.currid = c.id(+)
and d.doctype = cl.id(+)
...
and d.someattr = xN.id

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

← →
Sergey_Masloff (2005-09-06 18:35) [35]

Alexander Panov © (06.09.05 18:24) [32]
>А как ты запоминаешь идентификатор справочника валюты? В голове >держишь?
Зачем? Ведь корень справочника так и называется - справочник валют. Кроме того сделан эвристический поиск который наведет тебя даже если задать "ВАЛЮТЫ СПРАВ" "СЛОВАРЬ ВАЛЮТЫ" "ВАЛЮТЫ КЛАССИФИКАТОР" и многое другое. Кроме того так как это дерево то руками раскрыть пару уровней не проблема.
Кстати вся запись через единый интерфейс, руками в базу нет нужды писать ни разработчику ни программисту.
Понимаешь, если Диасофт сделали по ...ски это не значит что все подобного рода сделано так же. Диасофт я видел там действительно мрак.
Кстати тут с форума пару человек нашу систему видели изнутрей - ужаса и особых трудностей во въезжании не было, может если не лень будет подтвердят.

Sergey_Masloff (06.09.05 18:35) [35]
Кроме того сделан эвристический поиск который наведет тебя даже если задать "ВАЛЮТЫ СПРАВ" "СЛОВАРЬ ВАЛЮТЫ" "ВАЛЮТЫ КЛАССИФИКАТОР"

А если этот поиск выдаст тысячи полторы совпадений?

← →
Sergey_Masloff (2005-09-06 18:48) [37]

Alexander Panov © (06.09.05 18:44) [36]
Скажу так - на нашей реальной базе (20 млн. записей) при принятой по умолчанию степени соответствия я ни разу более 3 не встречал. Причем в 99% нужное было первым ;-) Хошь верь хошь не верь... Да правда удобно.

Sergey_Masloff (06.09.05 18:48) [37]

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

Плюсы и минусы, конечно, каждый для себя увидит-)

Эти варианты имеют право на жизнь во многих случаях.

← →
Sergey_Masloff (2005-09-06 18:55) [39]

А я в одном из проектов не только справочники, а и оперативные данные в одной таблице соединил. + таблица типов (иерархические). Для недостающих аттрибутов - блоб-поле для xml

Хранение справочников в одной таблице. Предлагаю обсудить идею. Найти похожие ветки