|
|
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Добрый день. Подскажите пожалуйста, какая схема лучше. Что будет работать быстрее? Во всех случаях используется три таблицы. Схема 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. Использоваться все это безобразие будет редко, только для связывания двух справочников, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2014, 15:16 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Raxta Подскажите пожалуйста, какая схема лучше. Что будет работать быстрее? Код: sql 1. 2. Все остальное безобразие За аргументами в поиск ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2014, 17:45 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Обычно я объединяю однотипные справочники, но в данном случае +1 к предыдущему оратору. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 01:28 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Raxtaбудет работать быстрее? А что это за критерий такой - "быстрее" ? Объясните, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 08:43 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Просто необходима универсальная система, что бы пользователи могли сами настраивать справочники и добавлять какие-то свои поля через GUI. Если дать пользователю свободу создавать каждый справочник в отдельной таблице - потом будет сложнее поддерживать разных пользователей. Быстрее в том плане, насколько быстро нужные данные забираться будут из справочников. В первом случае таблица растет в ширину и появляются избыточные поля, а так же необходимость сначала собрать запрос (какие поля для определенного справочника забирать), потом выполнить и вывести пользователю. Во втором случает есть необходимость хп или сложного запроса, что бы извлекать данные, при этом еще надо обрабатывать случаи, когда у одной записи в справочнике есть данные в доп.поле, а у другой нет. Вот и интересно, что лучше работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 09:09 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Raxta, Изменение пользователем структуры объектов базы данных - зло ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 12:02 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Cat2, Я знаю, что зло и я против этого, но вот тут необходимость такая есть и надо сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 12:14 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Курите EAV, но все равно это зло ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 12:51 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
2 таблицы хватит, зачем третья? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 13:01 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 13:02 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Ivan Durak, Гибрид первого и второго? Если в первой таблице pid != null, то создать во второй новый столбец? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 13:25 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
RaxtaIvan Durak, Гибрид первого и второго? Если в первой таблице pid != null, то создать во второй новый столбец? Таблица справочников и таблица столбцов, в таблице столбцов id, dict_id, field_name, field_type, field_valut_int, field_value_text, field_value_numeric. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 14:03 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Ivan Durak, Как тогда будет выглядеть ситуация, если у одной записи два дополнительных поля? Привязки к конкретному значению доп. полей то нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 14:14 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
RaxtaIvan Durak, Как тогда будет выглядеть ситуация, если у одной записи два дополнительных поля? Привязки к конкретному значению доп. полей то нет. у какой записи?? в справочнике 400 полей - значит будет 400 записей в таблице столбцов привязанных к этому справочнику. Всё! Что такое "дополнительные поля" не понимаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 14:22 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Ivan Durak, Есть например справочник "Города" в отличие от справочника "Овощи" у него есть дополнительное поле, выводимое в GUI, которое привязывает город к региону. В справочнике "Города" 200 позиций и у каждой свой регион, а в справочнике "Овощи" 150 позиций. Т.е. в одной таблице хранится запись вида <id>,<город>,<регион> и тут же хранятся записи вида <id>,<название_овоща>. Как при Вашей реализации на двух таблицах забрать регион определенного города, если во второй таблице нет привязки доп.поля к определенной записи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 14:26 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Люто плюсую первому ответившему. Мало того, если справочник по сути enum из предопределённого набора, то заместо суррогатного id можно использовать осмысленное уникальное значение. К таким данным легче писать запросы, легче анализировать их (запросов) результаты, а также можно безнаказанно захардкодить в коде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:30 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
RaxtaIvan Durak, Есть например справочник "Города" в отличие от справочника "Овощи" у него есть дополнительное поле, выводимое в GUI, которое привязывает город к региону. В справочнике "Города" 200 позиций и у каждой свой регион, а в справочнике "Овощи" 150 позиций. Т.е. в одной таблице хранится запись вида <id>,<город>,<регион> и тут же хранятся записи вида <id>,<название_овоща>. Как при Вашей реализации на двух таблицах забрать регион определенного города, если во второй таблице нет привязки доп.поля к определенной записи? у него есть дополнительное поле, выводимое в GUI, которое привязывает город к региону. Ну вот тебе доп запись в таблице столбцов = field_name = 'FK на регио', field_type = 'Int', field_value_int = 245 (собственно ссылка на регион) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 17:34 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Raxta что бы пользователи могли сами настраивать справочники и добавлять какие-то свои поля через GUIalter table add column, запрещен? Raxta Если дать пользователю свободу создавать каждый справочник в отдельной таблице - потом будет сложнее поддерживать разных пользователейПо-вашему одна большая куча легче в поддержке, чем та же куча рассортированная по маленьким кучкам, так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 17:41 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
Очень лысыйто заместо суррогатного id можно использовать осмысленное уникальное значение И будет очень весело, когда какой-нибудь пользователь решит, что это значение не особенно осмысленное и решить его переосмыслить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2014, 11:06 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
RaxtaПросто необходима универсальная система, что бы пользователи могли сами настраивать справочники и добавлять какие-то свои поля через GUI. Если дать пользователю свободу создавать каждый справочник в отдельной таблице - потом будет сложнее поддерживать разных пользователей. Быстрее в том плане, насколько быстро нужные данные забираться будут из справочников. В первом случае таблица растет в ширину и появляются избыточные поля, а так же необходимость сначала собрать запрос (какие поля для определенного справочника забирать), потом выполнить и вывести пользователю. Во втором случает есть необходимость хп или сложного запроса, что бы извлекать данные, при этом еще надо обрабатывать случаи, когда у одной записи в справочнике есть данные в доп.поле, а у другой нет. Вот и интересно, что лучше работает. Вот к этому описанию не хватает ещё пару - тройку реальных примеров с реальными данными справочников... У нас же как обычно - спрашивающие не озвучивают первоначальную постановку задачи, а предлагают сразу обсудить своё решение этой неозвученной проблемы, которое кстати (их решение) очень часто бывает кривым или по крайней мере далеко не оптимальным... Как то раз показали схему БД по учету техники (причём рабочую) в которой были таблицы: сист. блок, мышь, клавиатура, монитор, модем, принтер.... и естественно на каждую таблицу форма и отчет и естественно при появлении нового устройства (флешка, USB камера...) была переделка структуры и интерфейса из-за добавления новых таблиц..., а ведь никому даже в голову не пришло создать таблицу "Тип устройства" и таблицу "Устройства" с однотипными полями: код_типа_устройства, инв. №, Изготовитель, Сер. №, и т.д. Если вы хотите в разделе Проектирование БД получить реальную помощь - описывайте всегда проблему, а не своё видение её решения !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2014, 12:02 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
RaxtaДобрый день. Подскажите пожалуйста, какая схема лучше. Что будет работать быстрее? Во всех случаях используется три таблицы. Ещё раз всем повторяю, при проектировании структуры БД вы не должны думать о быстродействии. Т.е. может быть можно и подумать, но это нужно делать в самую последнюю очередь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2014, 12:02 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
vmag, Хотел подчеркнуть, а не зачеркнуть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2014, 12:04 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
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 - поле справочника." -- такого бытть не должно. Да и зачем -- тебе отдельной таблицы жалко ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2014, 12:07 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
vmag, Суть проблемы: необходимо сделать систему справочников, в которой может быть две ситуации. 1. Простой справочник вида ID-Значение. 2. Справочник соответствий вида ID-Значение-Значение Все это должно быть кастомизируемым, причем не только разработчиками, которые пилят систему, но и пользователями, которые вдруг решили у сущности добавить какое-то свойство и на это свойство повесить справочник. P.S. Я понимаю, что давать пользователям возможность менять или создавать что-то базовое - плохая идея, потому что рано или поздно все превратится в такую кашу, что ее потом не разгрести. Но есть такие личности, которым уперлась "универсальная схема, что бы все было и можно расширять пользователю". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2014, 08:18 |
|
||
|
Проектирование системы справочников. Что лучше
|
|||
|---|---|---|---|
|
#18+
RaxtaНо есть такие личности, которым уперлась "универсальная схема, что бы все было и можно расширять пользователю".В этой области рулит EAV. Никаких изменений в структуре базы. Только добавление записей. И SQL-запросы к EAV-у все унифицированы. Что немаловажно для разрабов-новичков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2014, 10:32 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38773948&tid=1540770]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 11ms |
| total: | 278ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...