powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование системы справочников. Что лучше
37 сообщений из 37, показаны все 2 страниц
Проектирование системы справочников. Что лучше
    #38771852
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день. Подскажите пожалуйста, какая схема лучше. Что будет работать быстрее?
Во всех случаях используется три таблицы.

Схема 1

Пояснение: при создании в DICT_FIELDS срабатывает триггер, который обрабатывает вставляемую или удаляемую запись и вставляет/удаляет столбец с данным типом и именем в DICT_VALUE.
При выборе данных программа смотрит по ID какие поля ей еще надо забирать и выводит их в GUI.

Схема 2

Пояснение: при создании в DICT_LIST если PID = null - справочник, PID != null - поле справочника. В таблице DICT_FIELDS создается запись с ссылкой на поле и запись в справочнике и в зависимости от типа в DICT_LIST пишется либо в int_value, либо в varchar_value.
При выборе соответственно для каждой записи справочника, где pid = ID справочника выбираются сведения из третьей таблицы и выводятся в GUI.

P.S. Все это безобразие в PostgreSQL. Использоваться все это безобразие будет редко, только для связывания двух справочников, например.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38772165
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Raxta Подскажите пожалуйста, какая схема лучше. Что будет работать быстрее?
Код: sql
1.
2.
create table dict1 (id, field1, field2, field3)
create table dict2 (id, field1, field2, field3)


Все остальное безобразие
За аргументами в поиск
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38772495
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Обычно я объединяю однотипные справочники, но в данном случае +1 к предыдущему оратору.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38772611
AO_MMM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Raxtaбудет работать быстрее? А что это за критерий такой - "быстрее" ? Объясните, пожалуйста.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38772626
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Просто необходима универсальная система, что бы пользователи могли сами настраивать справочники и добавлять какие-то свои поля через GUI. Если дать пользователю свободу создавать каждый справочник в отдельной таблице - потом будет сложнее поддерживать разных пользователей.
Быстрее в том плане, насколько быстро нужные данные забираться будут из справочников. В первом случае таблица растет в ширину и появляются избыточные поля, а так же необходимость сначала собрать запрос (какие поля для определенного справочника забирать), потом выполнить и вывести пользователю. Во втором случает есть необходимость хп или сложного запроса, что бы извлекать данные, при этом еще надо обрабатывать случаи, когда у одной записи в справочнике есть данные в доп.поле, а у другой нет. Вот и интересно, что лучше работает.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38772944
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Raxta,

Изменение пользователем структуры объектов базы данных - зло
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38772970
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Cat2,

Я знаю, что зло и я против этого, но вот тут необходимость такая есть и надо сделать.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773023
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Курите EAV, но все равно это зло
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773044
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 таблицы хватит, зачем третья?
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773045
prog123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
NafКурите EAV, но все равно это зло

Так это ОН или не ОН? 16683617
Что же вы молчите, знатоки?
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773077
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ivan Durak,

Гибрид первого и второго? Если в первой таблице pid != null, то создать во второй новый столбец?
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773137
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaIvan Durak,

Гибрид первого и второго? Если в первой таблице pid != null, то создать во второй новый столбец?
Таблица справочников и таблица столбцов, в таблице столбцов id, dict_id, field_name, field_type, field_valut_int, field_value_text, field_value_numeric.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773155
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ivan Durak,

Как тогда будет выглядеть ситуация, если у одной записи два дополнительных поля? Привязки к конкретному значению доп. полей то нет.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773168
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaIvan Durak,

Как тогда будет выглядеть ситуация, если у одной записи два дополнительных поля? Привязки к конкретному значению доп. полей то нет.
у какой записи?? в справочнике 400 полей - значит будет 400 записей в таблице столбцов привязанных к этому справочнику. Всё!
Что такое "дополнительные поля" не понимаю.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773172
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ivan Durak,

Есть например справочник "Города" в отличие от справочника "Овощи" у него есть дополнительное поле, выводимое в GUI, которое привязывает город к региону. В справочнике "Города" 200 позиций и у каждой свой регион, а в справочнике "Овощи" 150 позиций.
Т.е. в одной таблице хранится запись вида <id>,<город>,<регион> и тут же хранятся записи вида <id>,<название_овоща>. Как при Вашей реализации на двух таблицах забрать регион определенного города, если во второй таблице нет привязки доп.поля к определенной записи?
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773321
Очень лысый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Люто плюсую первому ответившему. Мало того, если справочник по сути enum из предопределённого набора, то заместо суррогатного id можно использовать осмысленное уникальное значение. К таким данным легче писать запросы, легче анализировать их (запросов) результаты, а также можно безнаказанно захардкодить в коде.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773601
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaIvan Durak,

Есть например справочник "Города" в отличие от справочника "Овощи" у него есть дополнительное поле, выводимое в GUI, которое привязывает город к региону. В справочнике "Города" 200 позиций и у каждой свой регион, а в справочнике "Овощи" 150 позиций.
Т.е. в одной таблице хранится запись вида <id>,<город>,<регион> и тут же хранятся записи вида <id>,<название_овоща>. Как при Вашей реализации на двух таблицах забрать регион определенного города, если во второй таблице нет привязки доп.поля к определенной записи?
у него есть дополнительное поле, выводимое в GUI, которое привязывает город к региону.
Ну вот тебе доп запись в таблице столбцов = field_name = 'FK на регио', field_type = 'Int', field_value_int = 245 (собственно ссылка на регион)
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773607
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Raxta что бы пользователи могли сами настраивать справочники и добавлять какие-то свои поля через GUIalter table add column, запрещен?
Raxta Если дать пользователю свободу создавать каждый справочник в отдельной таблице - потом будет сложнее поддерживать разных пользователейПо-вашему одна большая куча легче в поддержке, чем та же куча рассортированная по маленьким кучкам, так?
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773948
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Очень лысыйто заместо суррогатного id можно использовать осмысленное уникальное значение
И будет очень весело, когда какой-нибудь пользователь решит, что это значение не особенно осмысленное и решить его переосмыслить
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773968
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaПросто необходима универсальная система, что бы пользователи могли сами настраивать справочники и добавлять какие-то свои поля через GUI. Если дать пользователю свободу создавать каждый справочник в отдельной таблице - потом будет сложнее поддерживать разных пользователей.
Быстрее в том плане, насколько быстро нужные данные забираться будут из справочников. В первом случае таблица растет в ширину и появляются избыточные поля, а так же необходимость сначала собрать запрос (какие поля для определенного справочника забирать), потом выполнить и вывести пользователю. Во втором случает есть необходимость хп или сложного запроса, что бы извлекать данные, при этом еще надо обрабатывать случаи, когда у одной записи в справочнике есть данные в доп.поле, а у другой нет. Вот и интересно, что лучше работает.

Вот к этому описанию не хватает ещё пару - тройку реальных примеров с реальными данными справочников...
У нас же как обычно - спрашивающие не озвучивают первоначальную постановку задачи, а предлагают сразу
обсудить своё решение этой неозвученной проблемы, которое кстати (их решение) очень часто бывает кривым
или по крайней мере далеко не оптимальным...
Как то раз показали схему БД по учету техники (причём рабочую) в которой были таблицы: сист. блок, мышь,
клавиатура, монитор, модем, принтер.... и естественно на каждую таблицу форма и отчет и естественно при
появлении нового устройства (флешка, USB камера...) была переделка структуры и интерфейса из-за добавления новых таблиц..., а ведь никому даже в голову не пришло создать таблицу "Тип устройства" и таблицу "Устройства" с однотипными полями: код_типа_устройства, инв. №, Изготовитель, Сер. №, и т.д.
Если вы хотите в разделе Проектирование БД получить реальную помощь - описывайте всегда проблему,
а не своё видение её решения !!!
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773969
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaДобрый день. Подскажите пожалуйста, какая схема лучше. Что будет работать быстрее?
Во всех случаях используется три таблицы.


Ещё раз всем повторяю, при проектировании структуры БД вы не должны думать о быстродействии.
Т.е. может быть можно и подумать, но это нужно делать в самую последнюю очередь.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773970
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag,

Хотел подчеркнуть, а не зачеркнуть...
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38773971
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaДобрый день. Подскажите пожалуйста, какая схема лучше. Что будет работать быстрее?
Во всех случаях используется три таблицы.

Схема 1

Пояснение: при создании в DICT_FIELDS срабатывает триггер, который обрабатывает вставляемую или удаляемую запись и вставляет/удаляет столбец с данным типом и именем в DICT_VALUE.
При выборе данных программа смотрит по ID какие поля ей еще надо забирать и выводит их в GUI.

Схема 2

Пояснение: при создании в DICT_LIST если PID = null - справочник, PID != null - поле справочника. В таблице DICT_FIELDS создается запись с ссылкой на поле и запись в справочнике и в зависимости от типа в DICT_LIST пишется либо в int_value, либо в varchar_value.
При выборе соответственно для каждой записи справочника, где pid = ID справочника выбираются сведения из третьей таблицы и выводятся в GUI.

P.S. Все это безобразие в PostgreSQL. Использоваться все это безобразие будет редко, только для связывания двух справочников, например.


Вторая схема -- явноя бредятина, "если PID = null - справочник, PID != null - поле справочника." -- такого бытть не должно.
Да и зачем -- тебе отдельной таблицы жалко ?
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38774710
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag,

Суть проблемы: необходимо сделать систему справочников, в которой может быть две ситуации.
1. Простой справочник вида ID-Значение.
2. Справочник соответствий вида ID-Значение-Значение

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

P.S. Я понимаю, что давать пользователям возможность менять или создавать что-то базовое - плохая идея, потому что рано или поздно все превратится в такую кашу, что ее потом не разгрести. Но есть такие личности, которым уперлась "универсальная схема, что бы все было и можно расширять пользователю".
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38774802
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaНо есть такие личности, которым уперлась "универсальная схема, что бы все было и можно расширять пользователю".В этой области рулит EAV. Никаких изменений в структуре базы. Только добавление записей.
И SQL-запросы к EAV-у все унифицированы. Что немаловажно для разрабов-новичков.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38774811
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Буду смотреть в сторону EAV. Всем спасибо!
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38774865
Лопата
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaБуду смотреть в сторону EAV. Всем спасибо!
в pg (и именно в pg -- т.к. ddl там можно накатывать в транзакциях) не проблема нарисовать security definer ф-ю[и] [owner == superdba] (например как триггер[ы] на таблицу[s] метаданных), который будет [CREATE|ALTER] TABLE , со всеми плюшками оного (CONSTRAINTS, INDEXES, валидация и т.п.).

DROP [TABLE/COLUMN] запретить (юзверям). Сделать поле is_dropped в метаданных.

Будет в разы шустрее еава. но запросы все придется делать динамическими (пошивать в клиенте, или в хранимках) - по метаописаниям. то же - с интермордами.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38775107
Очень лысый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cat2Очень лысыйто заместо суррогатного id можно использовать осмысленное уникальное значение
И будет очень весело, когда какой-нибудь пользователь решит, что это значение не особенно осмысленное и решить его переосмыслить

Это уже отдельная песня. Про пользователей и их права. Опять таки, я оговорился про перечисление. Т.е. речь о частном случае. Иначе можно скатиться в бесперспективный холивар о том, что лучше: суррогат или естественный ключ. Так или иначе, но этап безоговорочного преклонения перед суррогатами и увлечения EAV у меня, к счастью, в прошлом.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38775679
babona
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
опять школота новички думают, что изобрели велосипед.
А когда начинается реальный life-цикл, то куда-то исчезают и остается жуткий говнокод.
без обид
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38775838
Raxta
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
babona,

Вот поэтому и решил сначала посоветоваться, что бы не плодить говнокода.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38775842
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> жуткий говнокод

Говнокод начинается, когда задачи ставят дебилы. Не бывает красивого решения кривой задачи. По определению.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38776523
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RaxtaВот поэтому и решил сначала посоветоваться, что бы не плодить говнокода. Да ладно чо стеснятся то, здесь все свои.
Каждый здесь открывал для себя EAV от перспектив которого захватывало дух - это ж какая экономия, можно только тремя таблицами обойтись, а власти старшие товарищи скрывают.
Всю скучную теорию можно выкинуть, пользователей можно не мучить допросами (у нас же гибкая структура), у ДБА можно не выпрашивать прав, и никаких тебе ограничений - полная свобода творчества.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38776804
scf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не нужно так делать - потом без поллитры не разберешься + потенциальные проблемы с быстродействием.

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

Если справочников реально много, причем большинство из них двухколоночные id, name, то имеет смысл сделать универсальное решение, примерно так:

DICTIONARY (ID, VERSION, CREATED, UPDATED, ENABLED, TYPE, TABLENAME, VALUE)

TYPE -это тип справочника. Если будет нужен справочник с бОльшим кол-вом полей, то они добавляются в отдельную таблицу со связью один-к-одному, а ее название вписывается в TABLENAME.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38776933
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Каждый здесь открывал для себя EAV от перспектив которого захватывало дух - ....
Вроде не кажный. Кто-то все же смотрел на это как на РМД вывернутую на изнанку. Поскольку типа оно живет в РМД, но РМД не задумывалось для оного. Т.е. на нем, скорей всего, достоинства РМД могут утрачиваться. И вообще.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38777809
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo Вроде не кажныйХорошо, вас эта болезнь не коснулась
scf Если справочников реально много, причем большинство из них двухколоночные id, name, то имеет смысл сделать универсальное решение, примерно такКакой?
В теме по универсальным справочникам я так и не услышал ни одного объективного довода ЗА (кроме уменьшения количества таблиц),
ВСЕ доводы были - ваши аргументы ПРОТИВ слабые, МНЕ так удобно,
поэтому дайте тезисно ВАШИ личные доводы ЗА такую структуру.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38777838
scf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257,

довод ЗА - это, очевидно, время добавления нового справочника. причем не только в базу, но и в приложение. Не нужно будет дублировать логику версионности и т.п.
...
Рейтинг: 0 / 0
Проектирование системы справочников. Что лучше
    #38777854
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
scf время добавления нового справочникаУ вас create table долго делается? Или не хотите идти на поклон к ДБА за правами на DDL? А придется, ибо мало справочник создать надо на него ссылатся.
scf но и в приложение а здесь-то какой затык? Долго разрабатывать форму для редактирования простейшего справочника? Или пользуетесь универсальной формой на select id, name from universal_dict where type=@type и не знаете как натравить эту форму на select id, name from @dict_table

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


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