powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Справочники - вместе или отдельно
66 сообщений из 66, показаны все 3 страниц
Справочники - вместе или отдельно
    #32439056
Klick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть куча таблиц: единицы измерения, отделы, склады и все такое. Хотим создать таблицу - глобальный справочник, который включал бы в себя все это вместе. Структура древовидная. id, parent, name и т.д.
Имеет ли смысл? Что лучше отдельно держать или вместе?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439158
GrayRat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мое мнение - нет. Учавствовал я в проекте где такое делалось (причем даже не так как планируете сделать Вы: в отдельный глобалный справочник выделялось лишь описание второстепенных сущностей, количество которых в принципе никогда не должно было перевалить даже за сотню), в итоге, хотя как и планировалось количество осталось на уровне, клиенты захотели дополнительных описаний этих самых сущностей - думаю Вы сами можете представить себе на что в итоге стала похожа таблица, к которую беспрерывно добавлялись столбцы, причем каждый конкретный столбец использовался для описание 1-3 сущностей.
Если у Вас действительно существует необходимость вести глобальный каталог сущностей, то думаю стоит его выделить в отдельную таблицу со, в принципе, сходной с указанной Вами структурой (назвать ее например dobj<ects>). Соответвенно таблицы описания каждого конкретного вида сущностей имеет смысл "прошить" кодом объекта.
Построение дерева в этом случае будет заключаться в выборке данных из БД (видимо в виде [запрос1] UNION [запрос2] ...) и обработке полученных данных на стороне клиента
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439271
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мое мнение - вместе.
пример серой крысы не показателен.

если планируется(и скорее всего так и будет) переменное количество характеристик каждого справочника, и переменное количество справочников, сделать подчиненную таблицу с характеристками.

и никакого гемора, три дня труда - 10 лет счастья. надо добавить справочник - пожалуйчта кнопка "добавить справочник" :-) надо добавить характеристику справочнику - пожалуйста! аналогичная кнопка :-)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439278
Paul A. Kuptsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Предложу способ, который здесь уже описывался, вроде бы. Все справочники, однотипные, которые влезают в структуру id, parent, name - засовываешь в одну таблицу. Справочники, у которых есть доп. поля выносишь в отдельные таблицы.
Можно доп. поля организовать в структуре, похожую на эту: "Registry" в базе данных
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439284
Paul A. Kuptsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
К пред. сообщению: в статье "Registry" в базе данных предлагается посмотреть идею хранения разнотипных записей в одной таблице.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439306
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
А мне вот интересно как в процессе проектирования вы получили такую сущность как "Общий справочник" ?

А если не получили, то зачем пихать разные сущности в одну таблицу ?

(Это не наезд. Мне действительно интересно. Если можно приведите коротенький пример.)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439375
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Klick

Прежде всего - нужно ответить на вопрос зачем вам это надо?

Потому что если хотите кнопку - типа "Добавить справочник" - вам совершенно необязательно хранить все в одной таблице - это вообще никак не связанные вещи.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439540
Фотография Green2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
База данных с переменным числом столбцов, может Вы XML базу данных делаете и не догадываетесь об этом?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439561
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Green2
все может быть - вы только скажите - что это за зверь такой - xml БД
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439638
Фотография Green2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давным давно, раньше реляционных баз данных появились иерархические базы данных. Они делались без теории, по наитию разработчиков.

Потом появилась реляционая теория и подтвердила, что нет ничего практичнее хорошей теории.

Пошло время, и иерархические базы вернулись в виде XML.

Смотри тут
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439674
Klick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А мне вот интересно как в процессе проектирования вы получили такую сущность как "Общий справочник
т.е. такого не может быть??? я не силен в теории, потому скажу только, что получили и получили. :)
А почему сие есть плохо? Нам кажется, что может получится очень даже хорошо.
Есть ли у кого нить опыт такой?
На счет кнопочек там или всякой такой ерунды - не пишите не тратьте время. Нам не кнопочки нужны, а хорошо работающая легко изменяемая структура. Дело в том, что только сейчас удалось пробить идею внедрения клинт-серверной технологии и начинаем только практически с нуля. Хочется сразу сделать так чтоб потом не было геморра. (И не говорите "что как раз вот это и будет геморр" не смешно :) )
Заранее спасибо !
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439692
Klick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати все заварилось с этой статьи http://www.compress.ru/Article.asp?id=2006
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439697
Klick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вы сами можете представить себе на что в итоге стала похожа таблица, к которую беспрерывно добавлялись столбцы - никакие столбцы у нас никуда не будут добавляться! С чего бы это? Будет тбл объектов, связей между ними и атрибутов.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439707
Фотография Green2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KlickБудет тбл объектов, связей между ними и атрибутов.
Ну совсем как XML!
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439809
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Klick

Кстати все заварилось с этой статьи http://www.compress.ru/Article.asp?id=2006

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

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

Green2
Дорогой грин, ну бросьте вы это лепет про xml - это формат хранения и ничего более
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439830
Klick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вы лучше сами для себя ответьте на мой вопрос - зачем вам это надо? Это просто непростительная наивность - выбирать путь просто на основе какой-то статьи - даже не понимаю зачем он нужен...

Нам это надо потому что хочется универсальности. Если делать как обычно то получится куча таблиц и с каждой придется возиться персонально, а так единый механизм.
На счет наивности - эт зря... Статья это не главное. Мы к этому уже давно шли. Вот теперь решили посоветоваться с "опытными товарищами".
Неужели никто на самом деле реально такого не разрабатывал?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439860
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нам это надо потому что хочется универсальности. \r
\r
Универсальности? А цену такой модели знаете? Или в статье об этом нет? :)\r
\r
Почитайте это /topic/5961&pg=1\r
\r
Неужели никто на самом деле реально такого не разрабатывал?\r
А что там такого сложного - чтобы его "разрабатывать"? Для такого подхода есть своя ниша
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439891
zayac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я тут /topic/78322\r
недавно пытался выяснить, есть ли у кого-то опыт по внедрению некой гибридной системы. Справочники хранятся не вместе, но и не раздельно. Структура вроде расчитана на\r
>никакие столбцы у нас никуда не будут добавляться! С чего бы это? Будет тбл объектов, связей >между ними и атрибутов\r
и хочу сделать ударение на то, что в моей ситуации:\r
>Записей в них от двух до тысячи, структура различная. В будущем будут появляться новые dbf и >модифицироваться существующие.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439908
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>Klick

Реально, все сведется к спору, кто круче, и никто вам дельного совета не даст, так как это уже идеология - кидать все в одну иерархическую таблицу или дробить на 1000 мелких. У тех и у других были как положительные примеры реализации, так и отрицательные. У меня вообще был МП, который даже для адресов не делал иерарх. табл., а дробил на 3-5 маленьких и все работало.... Так что решать вам и если вам больше подходит иерарх. табл., то в путь, а если сомневаетесь, то задавайте более конкретные вопросы.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439942
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Однозначно только то, что "справочники-отдельно" будут работать быстрее. А работа с ними будет программироваться не дольше (если сами не наплодите в каждом из них всяких отклонений от типовой схемы построения справочника ;-)).
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439959
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С другой стороны, для того, чтобы добавить "забытый" в свое время справочник, нужно будет программировать (соответственно, нужен будет разработчик), тогда как при наличии вшитой в систему идеологии работы со "справочниками-все-в-одном", достаточно будет только настроек (соответственно, нужен будет администратор системы). Вам, как разработчику, выгоднее нагрузить администратора, не так ли? ;-)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32439997
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bas
Вы невинмательно читаете топик - речь идет не об иерархических таблицах...

Urri
Вам, как разработчику, выгоднее нагрузить администратора, не так ли? ;-)

Да тоже самое можно сделать и для другой модели проектирования - я уже говорил - кнопку "добавить справочник" можно сделать и там и тут :)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32440037
Фотография Вовик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне кажется , идея с наличием универсальной таблицы имеет следующие
преимущества :
-она дает механизм организации единого ключа для сущностей разных типов
-кроме того, в ней можно хранить и строку - упрощенное название
( представление ) сущности.

Все это может оказаться полезным в случае разработки систем типа
бухгалтерских , когда заранее нельзя определить , какая аналитика
потребуется на том или ином счете. При использовании же данного подхода
select всегда будет один и тот же , будет лишь меняться его часть ,
связанная с where.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32440087
Фотография Green2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GrayRat Правильно заметил, на что похожа таблица, в которой постоянно меняются поля.

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
CREATE TABLE [dbo].[S_NOM27] (  -- Справочник промышленной продукции
 
	[RAZDNOM] [float] NULL ,
	[KNOM] [float] NULL ,
	[KBALK] [float] NULL ,
	[KNOMR] [float] NULL ,
	[KEIZ] [float] NULL ,
	[KZNZPT] [float] NULL ,
	[DRSX] [nvarchar] ( 6 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[PRRAZR1] [float] NULL ,
	[MP] [float] NULL ,
	[PRRAZR3] [float] NULL ,
	[GS] [float] NULL ,
	[KPERIOD] [float] NULL ,
	[KWIGR] [float] NULL ,
	[PERKWOT] [float] NULL ,
	[KWXOD] [float] NULL ,
	[NNOM] [nvarchar] ( 250 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[ZAKRIZD] [float] NULL ,
	[DOKLSX4] [float] NULL ,
	[OPGOD] [float] NULL ,
	[OPGODST] [float] NULL ,
	[P_1GOD] [float] NULL ,
	[DATEA] [smalldatetime] NULL ,
	[STATUS] [float] NULL ,
	[PRPR] [float] NULL ,
	[PROT] [float] NULL ,
	[PRRT] [float] NULL ,
	[RNKS] [float] NULL ,
	[PRRAZR2] [float] NULL 
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[nomenklatura2] (  -- суперсправочник
 
	[nomenklatura2] [bigint] IDENTITY ( 1 ,  1 ) NOT NULL ,
	[name] [varchar] ( 250 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[dictionary] [bigint] NOT NULL ,  -- код справочника из s_dictionary
 
	[cod] [bigint] NOT NULL            -- уникальный код в справочнике
 
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[s_dictionary] (  -- в этой таблице перечислены все справочники
 
	[dictionary] [bigint] IDENTITY ( 1 ,  1 ) NOT NULL ,
	[NameDictionary] [varchar] ( 50 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[DescDict] [text] COLLATE Cyrillic_General_CI_AS NULL ,
	[nomenklature] [bit] NULL 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

CREATE TABLE [dbo].[s_msh] (  -- справочник мощьностей
 
	[NOMPR] [float] NULL ,
	[KOTR] [float] NULL ,
	[KMSH] [bigint] NOT NULL ,
	[X5] [float] NULL ,
	[X6] [float] NULL ,
	[FL1] [float] NULL ,
	[FL2] [float] NULL ,
	[FL18] [float] NULL ,
	[PRAPK] [float] NULL ,
	[NPOZ] [float] NULL ,
	[ZAKR] [nvarchar] ( 30 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[KVX] [nvarchar] ( 30 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[EI] [nvarchar] ( 50 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[NMSH] [nvarchar] ( 255 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[NPOLN] [nvarchar] ( 255 ) COLLATE Cyrillic_General_CI_AS NULL 
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[s_okp] (  -- Отраслевой каталог продукции
 
	[okp] [bigint] NOT NULL ,
	[kd1] [int] NULL ,
	[kd2] [int] NULL ,
	[kch] [int] NULL ,
	[descript] [varchar] ( 255 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[levelTree] [int] NULL ,
	[parent] [bigint] NULL 
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[s_okpopt] (  -- Алкогольная продукция
 
	[okpopt] [bigint] NOT NULL ,
	[name] [nvarchar] ( 255 ) COLLATE Cyrillic_General_CI_AS NULL ,
	[ord] [tinyint] NULL 
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[s_room] (  -- кваритры
 
	[room] [bigint] NOT NULL ,
	[NameRoom] [varchar] ( 50 ) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[ord] [int] NULL ,
	[three] [text] COLLATE Cyrillic_General_CI_AS NULL ,
	[tree2] [text] COLLATE Cyrillic_General_CI_AS NULL 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32440089
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuri
Вы невинмательно читаете топик - речь идет не об иерархических таблицах...


Сначала как раз про них и шла речь, потом разбили ее на несколько, но смысл не изменился... Не надо придираться к словам.

Я хотел сказать, что мы не сможем однозначно посоветовать ту или другую структуру данных пока автор не определится с конкретными требованиями и не будет задавать более напрвленных вопросов, так как у той и другой структуры есть свои - и +.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32440268
Фотография UK0IAI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Klick
Универсальный справочник на все и вся..

Есть один мощный аргумент в пользу этой идеи, но только он зависит от Вашего "боевого начала".

В 93 году, я внедрял системы бух_учета, где задача универсальности была решена в полном объеме. (1С это и не снилось).

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

Где просто, в виде списка (в одну или в две колонки) предъявлялось
Имя поля по русски........Поле ввода значения, примерно вот так:

Код: plaintext
1.
2.
3.
Цех.......... XXX            Начисленно...... XXXXX.XX
Участок.......XX             Дебет..............XX-XX
таб.номер.....XXXXXXXX       Кредит............. XX_XX
вид оплаты....XXX


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

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

Все отчеты системы - имели также, универсальной описание в журнале БД, и сами все получались.

Понятно, что разработчкии этой системы потратили много труда для системного программирования, когда, например, все справочники очень удобно отражались всего через ОДНУ форму представления....ну понимаете, они ведь все там пикселы (символы),...длины полей... просчитывали на лету....и на лету...все отражали...

Увы, наши тулзы визуального проектирования не любят таких фишек. Но я бы рискнул.

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

.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32441868
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО - справочники(да и не только) можно хранить в четырех таблицах - (класс, поля класса, экземпляр класса, значения полей для экземпляра). Всегда лучше править данные, чем метаданные(если разработка перманентная). Скорость работы на такой структуре - приемлемая. Гибкость - высокая. А возможность удаленного сопровождения может перевесить все остальные аргументы. Опять же клиентские места генерируются на лету, прозрачная репликация и ещё много вкусных плюшек.
Вещь очень жизненная, хоть и далеко не новая.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32452393
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> ИМХО - справочники(да и не только) можно хранить в четырех таблицах - (класс,
> поля класса, экземпляр класса, значения полей для экземпляра).
> Всегда лучше
> править данные, чем метаданные(если разработка перманентная). Скорость
> работы на такой структуре - приемлемая. Гибкость - высокая.

Уважаемый дон приведет пример и цифры в подкрепление тезиса о приемлемости скорости работы такой структуры?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32452459
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я говорил о следующих цифрах(текущий проект): классов~110, полей классов~450, экземпляров классов(объектов)~46500, полей классов~316400
При этом имеется наследование в классах и хранится вся история изменений. Различных АРМов-10, клиентов-25, поток запросов весьма интесивный.
Неужели лучше сделать 110 таблиц? И опять же ИМХО - универсальных решений не бывает, есть лишь удачные в определенных ситуациях паттерны проектирования.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32453351
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Я говорил о следующих цифрах(текущий проект): классов~110, полей
> классов~450, экземпляров классов(объектов)~46500, полей классов~316400
> При этом имеется наследование в классах и хранится вся история изменений.
> Различных АРМов-10, клиентов-25, поток запросов весьма интесивный.

25 клиентов - это хорошо. А что за ОС/СУБД?

Если не секрет, как хранится история? Как организовано наследование? Если не лень, маленький пример одного справочника (подойдет на пальцах).

> Неужели лучше сделать 110 таблиц?

Смотря по задаче.

> И опять же ИМХО - универсальных решений
> не бывает, есть лишь удачные в определенных ситуациях паттерны
> проектирования.

Спору нет, согласен.

С другой стороны, справочники - штука реюзабельная, поэтому здесь можно скорее говорить не об универсальности решения, а о предпочтениях разработчика. ;)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32453719
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Секретов нет - Yaffil(Classic)/W2000. А пример ... могу скриншот выслать. Наследование - деревянное. Вся логика наследования и сохранения истории - триггерная(принцип неизменности ИК и создание новой записи как архивной, пометка удаленной записи). Возможны взаимные ссылки, отношения много-ко-многим. Все не раз описано в статьях.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32453751
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хочу поделится своей структурой справочников:

Я использую объектный стиль проектирования БД

Что такое самы простой справочник? Это ID и Name, сделайте для этого таблицу:

create table Objects
(
OID int not null identity(1,1),
Name varchar(128),
primary key clustered ( OID )
)
go

Несколько справочников у вас уже будет. Чтобы их различать введите поле типизации:

create table Objects
(
OID int not null identity(1,1),
Name varchar(128),
Class varchar(32) not null default ('DBObject'),
primary key clustered ( OID )
)
go

Если в вашем справочнике есть доп. атрибуты сделайте их в доп. таблице (то бишь наследование :)

create table Clients
(
OID int not null,
Address varchar(255),
primary key clustered ( OID )
)
go

Добавление записей в простой справочник

create procedure DBObject_Create
@OID int output
@Name varchar(128),
@Class varchar(32)
as
insert into Objects ( Name, Class )
select @Name, @Class
select @OID = @@identity
go

Добавление записей в справочник клиентов

create procedure DBOClient_Create
@OID int output,
@Name varchar(128),
@Class varchar(32),
@Address varchar(255)
as
exec DBObject_Create @OID output, @Name, @Class
insert into Clients
select @OID, @Address
go

выборка данных для класса 'DBObject'

select * from Objects where Class = 'DBObject'

выборка данных для класса 'DBOClient'

select * from Objects o inner join Clients c on c.OID = o.OID and o.Class = 'DBOClient'

и так далее. Механизм наследования понятен?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32453943
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> А пример ... могу скриншот выслать.

Спасибо, не нужно. ;)

> Наследование - деревянное.

Ага. Значит, еще и иерархия для объектов есть. А если захочется классификатор справочников (проще два раза щелкнуть мышью, чем листать список) - плюс еще пара таблиц. ;) Плюс связи (если они множественные). ;)

Конечно, таблиц не 110, но imho получается не так просто, как хотелось бы. О чем, собственно, и речь. В общем, как правильно замечено, [цитата] универсальных решений не бывает, есть лишь удачные в определенных ситуациях паттерны проектирования [конец цитаты]. ;)

> Вся логика наследования и сохранения истории - триггерная (принцип
> неизменности ИК и создание новой записи как архивной, пометка удаленной
> записи).

Понятно. Вполне себе продакшн решение. Таймер есть или временные метки произвольны (или другая логика истории)? Какая security model используется?

> Все не раз описано в статьях.

Это понятно. Только судя по _подавляющему большинству_ форумов, и Дейта не всякий потрудился прочесть, не говоря о большем. ;)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32454216
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PostgreSQL userКонечно, таблиц не 110, но imho получается не так просто, как хотелось бы. Получается просто и таблиц именно 4, а не больше.
PostgreSQL userТаймер есть или временные метки произвольны (или другая логика истории)? Какая security model используется?

Временные метки, как вы понимаете, должны быть пользовательские и системные. А security model практически не используется в БД, только security ОС. Но только справочники тут не причем :-)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32454389
Фотография Вовик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Могун
А не могли бы вы поподробнее описать вашу модель
и выслать скриншоты на мыло : lopatinve@mail.ru
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32455463
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Получается просто и таблиц именно 4, а не больше.

ОК, обошлись 4 таблицами - хорошо. Мне потребовалось бы больше.

Собственно, к чему я речь вел (с примерами не получилось, классификация тоже, как выяснилось, не нужна, права на объекты раздавать не нужно - ну, на нет и суда нет): есть смысл объединять в одной структуре _однотипные_ справочники. Дешевле и логичнее [грустную историю про мухи и котлеты пересказывать не буду].

> Временные метки, как вы понимаете, должны быть пользовательские и системные.

Откуда вдруг взялись пользовательские? У пользователей время течет отлично от системного (час за два)? Интересная постановка задачи.

> А security model практически не используется в БД, только security ОС.

Не понял, как это "практически не используется"? Т. е., здесь используется, а здесь рыбу заворачивали? ;)

> Но только справочники тут не причем :-)

Это только так кажется.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32456171
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PostgreSQL userОткуда вдруг взялись пользовательские? У пользователей время течет отлично от системного (час за два)? Интересная постановка задачи.
Мне непонятна ваша ирония... Пользовательская временная метка - это время наступления события с точки зрения пользователя. Системная - время, когда об этом стало известно системе(текущее системное). Простой пример - ставка НДС 18% вступила в действие с 01.01.2004 00:00:00. Если запись об этом была сделана заранее - это одно, если задним числом - требуется перерасчет.
PostgreSQL user есть смысл объединять в одной структуре _однотипные_ справочники. Дешевле и логичнее
Что по-вашему есть однотипные справочники? И что есть классификация?

PostgreSQL userТ. е., здесь используется, а здесь рыбу заворачивали? ;)
Смешно... Но в таком тоне диалога не получится. Изложите свои мысли понятнее.

> Но только справочники тут не причем :-)

Это только так кажется.

А это вообще из области - догадайтесь-ка в каком кармане у меня фига - глубокомысленно...
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32456775
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Пользовательская временная метка - это время наступления события с точки
> зрения пользователя.

Ага. Понятно. Несколько непривычная интерпретация, поэтому и возник вопрос.

> Системная - время, когда об этом стало известно системе(текущее системное).

В контексте вышенаписанного тоже понятно.

> Что по-вашему есть однотипные справочники? И что есть классификация?

Однотипные - описывающие близкие по смыслу сущности (единицы измерений, (экс-) территориальные единицы etc). Классификация... не знаю, какой синоним здесь уместен. Группировка сущностей по некоторым признакам?

> Смешно...

Рад, что повеселил.

> Изложите свои мысли понятнее.

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

> А это вообще из области - догадайтесь-ка в каком кармане у меня фига -
> глубокомысленно...

;) ОК, подробнее: если security model предполагает ограничения на уровне таблиц, то будет проблематично ограничить доступ пользователей к справочникам, если все они описаны в рамках одной структуры. Понятно, что это не единственно возможный вариант модели, но - один из самых простых. Поэтому не стал бы утверждать, что организация справочников и модель ограничения доступа независимы.

Хотелось обратить внимание на то, что организация хранения справочных данных - это не только проблема технического характера.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32457259
immutable
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У подхода одного справочника есть некоторые недостатки:
1) мы ослабляем контроль ссылочной целостности, т.к., например, вместо ссылки на физ. лицо можно поставить ссылку на организацию, и сервер нас за это не отругает.
2) Сложнее делать разграничение прав пользователей.

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

Владимир
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32457623
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
immutable :

это не недостатки системы, это недостатки программиста
ссылочная целостность легко реализуется через специальный механизм, пример из практики:

create procedure DBOThing_Delete_DBOMeasure
@OID OID
as
declare @Name String

select @Name = (select top 1 o.Name
from Things t
inner join
Objects o
on o.OID = t.OID
where
t.MeasureOID = @OID)

if @Name is not null
begin
raiserror('Единица измерения ссылается на объект учета <%s>, 11, 1, @Name)
return 1
end
go

Если пользователь попытается удалить Единицу измерения, то специальный движок вызовет все процедуры, где первый класс любой, а второй класс не выше DBOMesaure, подставляя туда свой идентификатор. Если хоть один облом произойдет, удаления не будет. Кроме того я сделал процедуру, которая сканирует все таблицы где есть поля типа OID (это тип от int, используется для идентификатора объекта) и есть значения удаляемого объекта.

create procedure DBObject_CheckConstraints
@OID OID
as
declare @Column sysname,
@Table sysname,
@CharOID String,
@Count int

select @CharOID = convert(varchar(32), @OID)

delete DeletedObjs

declare Walker cursor local fast_forward for
select c.name, o.name
from syscolumns c
inner join
systypes t
on t.xusertype = c.xusertype and
t.name = 'OID'
inner join
sysobjects o
on o.id = c.id and (o.xtype = 'U' or o.xtype = 'V')
where o.name <> 'Blocks'

open Walker
fetch next from Walker into @Column, @Table
while(@@FETCH_STATUS <> -1)
begin
if(@@FETCH_STATUS <> -2)
begin
exec( 'insert into DeletedObjs select ' + @Column + ' from ' + @Table + ' where ' + @Column + ' = ' + @CharOID)
select @Count = (select count(OID) from DeletedObjs)
if @Count <> 0
begin
raiserror('Нельзя удалить объект. На него есть ссылка в поле <%s> таблицы <%s>', 11, 1, @Column, @Table)
return 1
end
end
fetch next from Walker into @Column, @Table
end
close Walker
deallocate Walker
go

если осталась хоть одна ссылка, про которую забыли программисты, то система выругается, типа в таблице <> в поле <> есть ссылка
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32457684
immutable
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Может конечно это недостатки программиста,
но мне больше нравится _уже_ реализованная на уровне СУБД
декларативная ссылочная целостность, которая надежнее
рукописных процедур с использованием динамического SQL.

Владимир
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32461894
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
immutableМожет конечно это недостатки программиста,
но мне больше нравится _уже_ реализованная на уровне СУБД
декларативная ссылочная целостность, которая надежнее
рукописных процедур с использованием динамического SQL.

Ну-ну, что-то вы запоёте, когда этих справочников станет больше ста...

------------------------------------------------------------------
когда я ем, я глух и нем, когда я пью, вообще дурной
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32462126
Dik76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
Универсальный справочник на все и вся.. 


Есть еще минусы:
1. При разработки требуется создание администраторской утилиты для работы 2. и при проектировании скажем с использованием case средств, обычная реляционная модель значительно лучше читается, обеспечивается наглядность и простота восприятия для кодеров.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32462151
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Могун

Если у вас в какой-либо достаточно изолированной подсистеме будут использоваться сразу более 100 справочников - вы и так и так запоете :)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32462268
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> и при проектировании скажем с использованием case средств

Хм... а что, есть вменяемые case средства для проектирования структуры базы данных?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32462452
Dik76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>PostgreSQL user
Это зависит от СУБД. Разные Case средства по разному адаптированы под них, вплоть до версий. Идеальных конечно нет (а жаль), но ручками то еще хуже, если документации не делать, так через пару месяцев, только по данным и будешь понимать что где лежит :), а если данные в одной куче...
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32462597
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Это зависит от СУБД.

Смотря по задаче.

> Идеальных конечно нет

Imho, приемлемых нет, не говоря об идеальных.

> но ручками то еще хуже

Да ну? Возможно, медленнее, но точно не хуже.

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

Хм... уважаемый дон слышал о самодокументировании? ;)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32462702
Dik76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу case средств остаюсь при своем мнении. При проектировании их активно использую. Во всяком случае на начальном этапе разработки скорость разработки значительно выше. При сопровождении конечно их эффективность снижается, но надо учитывать еще тот факт, что при проектировании не приходится думать о диалекте SQL конкретной СУБД.

PostgreSQL user Хм... уважаемый дон слышал о самодокументировании? ;)

Не слышал, ссылочку киньте.
Но как позвольте узанть оно(самодокументирование) будет протекать, если справочники будут создаваться в объектной модели, т.е. юзверями?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32463522
immutable
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To Могун:
А что я должен запеть?
Если они такие одинаковые, то кто мне мешает их создать скриптом
в CASE средстве? Приличные CASE позволяют использовать средства
малой механизации,т.е. дают ползать VBScript'ом по своей объектной модели.

To PostgreSQL user:
Какими CASE средствами вы пользовались и чем конкретно они не устраивают?

Владимир
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32464961
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
immutableА что я должен запеть?
Если они такие одинаковые, то кто мне мешает их создать скриптом
в CASE средстве? Приличные CASE позволяют использовать средства
малой механизации,т.е. дают ползать VBScript'ом по своей объектной модели.

Я имел ввиду вашу лебединую песню ПОСЛЕ завершения процесса проектирования. Клиент для такой базы нужен? Если это чисто теоретические изыскания, то ради бога... И объясните мне, пожалуйста, что такое ОДИНАКОВЫЕ справочники.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32465005
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Справочники)
Я б тут выделил несколько позиций:
1) Тупые справочники, которые состоят из конечного неизменяемого количества опций:
Резидент/нерезидент, Да/Нет,Пол-Муж/Жен и т.д.
Как я мыслю, для таких вообще справочники НЕ нужны...
Делается просто check constraint, и всё...
2) Справочники, которые являются пополняемыми и которые можно привести
к виду - Код/Значение, например - цвет изделия, единица измерения, тип упаковки и пр...
Их действительно можно объединить в одну таблицу
3) Справочники сущностей: Контрагенты, Продукция и пр...
на каждую сущность естественно своя таблица...
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32465041
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да?

Тут вот говорили недавно, что в медицинском справочнике "Пол" не 2, а 5 значений:
- Не установлен
- Мужской
- Женский
- Бывший мужской
- Бывший женский

Представь, что твоя супер-программа на check-constraint'ах изначально сделана для гражданского использования, а потом ты ее продал медицинской организации.
Менять ограничения в базе на физическом уровне? По-моему, это гораздо сложнее на этапе поддержки, чем просто добавить три недостающих пола в соответствующий справочник. И потом, у тебя сразу появляется версионность. Эта база - для клиента типа А, а эта - для типа Б. А потом еще появляется клиент типа В. Не боишься запутаться?
Не так ли? ;-)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32465075
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ещё раз повторюсь - Всегда лучше править данные, чем метаданные(если разработка перманентная и к тому же удаленая).

Использовали ли те, кто отстаивает свою модель справочников, эту модель в боевых условиях, а не в вакууме?
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32465088
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не пугайте меня так, я в этих водах плаваю уже много лет.
Не запутаюсь...))
Тоже интересный вариант, возмем например поля , где нужно ставить Да/Нет
в другом Да/Нет/Незнаю. И как быть? Создавать два справочника? Глупо.
Вообще работу по заполнению/контролю таких полей лучше перенести на приложение, а не на сервер. Все равно на рабочей станции вам таки или иначе это придется делать.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32465690
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Тут вот говорили недавно, что в медицинском справочнике "Пол" не 2, а 5 значений:

Название справочника? Название стандарта, по которому проведена классификация? Сильно похоже, что это обычная отсебятина.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32465830
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, может, и отсебятина - мне она понравилась именно как парадоксальный пример того, как даже самый вроде бы постоянный справочник непредсказуемо может разрастись. ;-)))
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32466294
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> парадоксальный пример того, как даже самый вроде бы постоянный справочник
> непредсказуемо может разрастись.

Imho, тривиальный пример человеческой глупости. Ничего парадоксального или интересного.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32466299
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
много лет назад некоторые люди приводили как пример человеческой глупости идею летательного аппарата тяжелее воздуха.
и не находили в этой идее ничего парадоксального или интересного.

но были и другие люди, которые находили.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32466907
Dik76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Тут вот говорили недавно, что в медицинском справочнике "Пол" не 2, а 5 значений:

Получается что по полу еще и историю надо хранить :)
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32467439
PostgreSQL user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> но были и другие люди, которые находили

В дерьме бриллиантов нет.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32467528
immutable
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Одинаковые справочники - это справочники имеющие
одинаковую структуру (плоский, иерархический), одинаковый набор полей.

А по поводу пользовательских интерфейсов, так их тоже можно создавать
на основе метаданных.

Владимир
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32468832
Могун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2immutable
Плоский справочник - частный случай иерархического, а совпадение по структуре - это типа ID, NAME ? И если их хранить в одной таблице, все равно нужон тип этого "одинакового" справочника. Спрашивается, зачем огород городить ради ТЕОРЕТИЧЕСКИХ выгод....
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32469340
immutable
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мы наверное не поняли друг друга.
Я и не предлагаю все помещать в один справочник.
Каждому справочнику - свою таблицу.
А выгоды от контроля ссылочной целостности - сугубо практические.

Владимир
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32473268
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кого интересует конечный результат,а не дискуссия по данному вопросу то, как говориться,-милости просим!
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32476634
Ramil Mustafin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дж.Дейт во "Введении в системы реляционных баз данных" отмечает всего 3 возможных подхода к хранению данных:
Хранение первичных данных,
Хранение уже обработанных данных,
Хранение данных в промежуточном виде.

Разобьем всю базу на две части:

1) Первичные данные – документы (приходные\расходные накладные, приказы, и т.д. – описанные в законодательстве, ведомстве, предприятии основные документы, как правило имеют бумажный вариант):
- записывается целиком весь документ,
- количество документов велико,
- чтения документов происходят весьма редко.

2) Вторичные (обработанные) данные:
- при записи первичного документа происходит обработка бизнес правил – записываем изменения во вторичные данные (справочники, реестры, счета и т.д.), относящиеся к данному первичному документу.
- объем вторичных данных ограничен,
- обращения происходит достаточно часто (практически вся работа пользователей происходит с вторичными данными).

При таком подходе возможно создание «универсальной» структуры хранения учетных данных, практически без потери скорости при масштабировании (росте объема базы), поскольку, в основном, работаем с вторичными (обработанные, малый объем) данными.
Естественно теряем в объеме, но это не так критично в последнее время.
При возникновении такой «универсальной» структуры появляется возможность повторного использования не только самой структуры, но и методов работы в ней со «стандартными» документами (накладные и т.д.), перестраивая только бизнес правила.
...
Рейтинг: 0 / 0
Справочники - вместе или отдельно
    #32477441
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ramil Mustafin

Разобьем всю базу на две части:
...
- чтения документов происходят весьма редко.
...
- обращения происходит достаточно часто (практически вся работа пользователей происходит с вторичными данными).


Я, честно говоря, не понял :) Вы бы привели какой-нибудь пример
...
Рейтинг: 0 / 0
66 сообщений из 66, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Справочники - вместе или отдельно
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]