|
|
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Petro1232. У меня есть один такой проект от которого отказался заказчик из-за того что в БД 100 таблиц - справочников к одной главной таблице (ROT) Хм. Заказчики бывают и более талантливыми идиотами - но что из этого следует? С другой стороны, в одном проекте коллеги сделали совершенно замечательную фигню. Им показалось, что справочники "слишком маленькие", и поэтому они сделали справочники "два в одном" - то есть вместо справочников А и Б сделали справочники вида А cross join Б. Как Вы догадываетесь, работать с этим было офигенно удобно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 12:39 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
softwarer"слишком маленькие" я про такой критерий не говорил. Заказчик выбрал не ROT и это его право. Моё IMHO по теме я сказал: /topic/294156&pg=1#2678055 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 12:56 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
> ваша структура на мой взгляд подходит для математических систем Если бы. ;) На самом деле это очень простой вариант реализации справочника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 12:59 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
> Другой пример: средство связи от почтового адреса > (разного в разных странах кстати) до URL Великолепный пример. Давайте чуть подробнее на нем остановимся. Если я правильно понимаю, Вы полагаете, что целесообразно иметь некий универсальный справочник под именем "средства связи"? > _Внимательно_: Извините, пропустил фразу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 13:02 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
> Высота (высокий, низкий) > Глубина (глубокий, ооочень глубокий) > Бугорки (есть, нет) ;))) > Это ведь справочники? А сами-то Вы как думаете? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 13:07 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Petro123Заказчик выбрал не ROT и это его право. Безусловно. Я к тому, что "мнение заказчика" - нисколько не аргумент в разговоре о технической стороне дела. Такой аргумент мог бы быть уместен в беседе о "продаваемости" того или иного варианта решения. К сожалению, зависимость между этими двумя факторами... весьма нелинейна, назовем так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 13:07 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
> потребность по ходу эксплуатации уточнить классификацию Справочник и классификатор - суть разные вещи. Конечно, возможна (часто - необходима) связь между классификатором и справочниками, но - подчеркну - это абсолютно разные структуры данных для разных целей. > вполне реальна Imho информативность приведенных характеристик стремится к нулю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 13:13 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Petro123 wrote: > locky > > после записи в справочник приходится вызывать процедуру проверки > структурной целостности элемента справочника, потому как накладки таки > имели место быть. > > не могли бы вы привести пример? Поскольку все референсы идут к одной и той же таблице, содержащие экземпляры разных объектов, запросто вместо счета можно сослаться по подразделение. Я боролся путем процедуры доп. контроля при записи. Выше люди показывали еще один оччень интересный способ (надо над этим подумать). > > *IMHO* > Я так понял особенности: > EAV: > *+* > - хранение переменного количества атрибутов > - атрибуты развёрнуты по вертикали а не по полям (зависит от заказчика) а это пофиг... хошь - так показывай, хошь - так... на физическом то уровне всё равно - всё вертикально :-) > *_* > > - нет связей по целостности данных на уровне БД ага :-( хотя физические есть, и, как писалось выше, можно реализовать и логические связи (хотя если промахнешься в подчиненной табличке с типом объекта....) > - для вывода шахматки приходится извращаться недопонил. при чем тут отображение данных к хранению? из 3НФ что, легче? > - больше логики и кода переносится на БД и его язык минус ли это? кому как. > - проблемы в использовании визуального проектирования "морды" в > bound-присоеденённом режиме к БД. про "боунд" - не понил, а проблем в проектировании интерфейсов вроде как не было - всё эдак ровненько пострижено, покрашено, единообразно... Юзеров учить легче, опять таки. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 13:55 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
locky > - для вывода шахматки приходится извращаться недопонил. при чем тут отображение данных к хранению? из 3НФ что, легче? > bound-присоеденённом режиме к БД. про "боунд" - не понил, а проблем в проектировании интерфейсов вроде как не было - всё эдак ровненько пострижено, покрашено, единообразно... Юзеров учить легче, опять таки. 1. всё-таки имеет значение при прочих равных условиях , т.к. если данные по горизонтали (в полях) и их нужно развернуть по вертикали (записях) на клиента, да ещё редактировать, то это не просто. Если, например, характеристики товара динамические, то на клиенте их в поля выводить нет никакого смысла. 2. Много компонентов и клиентских библиотек сами формируют текст запроса UPDATE.... и заточены работать с "исторической" ROT схемой а не EAV и моделью Тенцера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 14:23 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Sidorov AntonДобрый день Сейчас занимаемся проектированием БД. И поступило предложение организовать все справочники в одной таблице. структура такая: pk-ключ,nspr-номер справочника,nv-номер значения,v-значение Как вы считаете что будет в плане производительности лучше: использовать 10 справочников каждой в своей таблице или же организовать 1 таблицу со значениями всех справочников?Я использую такую структуру. На производительности выборки данных это практически никак не сказывается. При использовании индексов, в которых первым полем идет код справочника, зана выборки ограничивается в таблице только множеством записей указанного справочника. Поэтому, это еще не извествно, как будет происходит выборка быстрее, каогда у вас несколько join к одной таблице с разными условиями, или тоже, но к разным таблицам. Может быть потеряна производительность при поддержке целостности базы данных на триггерах. В MS SQL при такой структуре справочников на консрейнах не получится. Но это уто уже засит от качества реализации триггера. Хотя, введя искуственные поля в связанные таблицы, значения которых всегда равны коду справочника, можно использовать и констрейны. На счет скорости программирования - много раз убедился в том, что это было хорошое решение. Справочники добавляются на лету, без остановки системы, без необходимости измень структуру базы данных (за редким исключением). В интерфейсной части со всеми справочниками работают две-три формы. Легко описывать состав справочников, легко ими управлять. Это очень важно при сопровождении тем программистам, которые не являеются разработчиками. Объясняя им показываешь - вот одна таблица, вот два индекса, вот одно поле код справочника - включай в запросы. А как бы объявнял, когда были бы десятки таблиц, не знаю. ИМХО. Старшее поколение правильно предлагает. Недостаков нет, одни преимущества. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 14:53 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
PVP не могли бы вы рпивести скрин управления и модификации такими "справочниками в одном флаконе". У нас это называется классификатор, и он может менятся - переподключаться пользователем. ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 15:14 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Petro123 PVP не могли бы вы рпивести скрин управления и модификации такими "справочниками в одном флаконе". У нас это называется классификатор, и он может менятся - переподключаться пользователем. ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!Счас попробую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 15:17 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
http://www.softbas.com.ua/forum/index.php?act=module&module=gallery&cmd=si&img=22 - это окно для настройки справочников ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 15:20 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
http://www.softbas.com.ua/forum/index.php?act=module&module=gallery&cmd=si&img=23 - общий ввод данных в справочники ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 15:24 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Petro123У нас это называется классификатор, и он может менятся - переподключаться пользователем.Ну, наверное "подключаться пользователями" - это перебор. Все мои попытки и эксперименты моих знакомых дать возможность девушкам-пользователям, а особенно продвинутым спецам-пользователям добираться в те места, где подключаются справочники, заканчивались тем, что отключали им вообще доступ к возможности настроек. Подключение справочников - это по сути настройка структуры базы данных, а именно связей между наборами данных. Если бы это были отдельные таблицы, то я сказал бы связей между таблицами, констрейнов. И к этой работе лучше пользователей не подпускать. Пусть этим программисты занимаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 15:34 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Другой пример: средство связи от почтового адреса > (разного в разных странах кстати) до URL Великолепный пример. Давайте чуть подробнее на нем остановимся. Если я правильно понимаю, Вы полагаете, что целесообразно иметь некий универсальный справочник под именем "средства связи"? Давайте. Открыл тему т.к. в единую таблицу точно не укладывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 15:45 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
PVPИМХО. Старшее поколение правильно предлагает. Недостаков нет, одни преимущества. Как вы категоричны.... Новым разработикам вы тоже поясняете, что в таблице A, в колонке B могут быть только 3 значения потому что так в триггере написано ? по subj - 1 Производительность хуже, конечно, но не так чтобы очень. (ввиду отсутствия каких-либо разъяснений у автора треда, приходится давать такую умозрительную оценку) 2 "читабельность" схемы БД значительно хуже. Тут без вариантов. 3 поддержка целостности данных значительно хуже. 4 реализация редактирования и добавления справочников лучше/проще. (что увеличивает опасность превращения базы в выгребную яму, как тут уже было сказано. Кроме того я не понимаю зачем для единого редактора справочников (например) они все должны быть в одной таблице) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:30 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Alexey Kudinov PVPИМХО. Старшее поколение правильно предлагает. Недостаков нет, одни преимущества. Как вы категоричны.... Новым разработикам вы тоже поясняете, что в таблице A, в колонке B могут быть только 3 значения потому что так в триггере написано ?Ну я же сделал приставку "Имхо", это смягчает мою вину. К тому же, почему обязательно в триггере? В систему настройки справочника добавьте соответствующее свойство поля, введите это ограничение, и пусть триггер считывает его из свойств и применяет. Alexey Kudinov1 Производительность хуже, конечно, но не так чтобы очень. (ввиду отсутствия каких-либо разъяснений у автора треда, приходится давать такую умозрительную оценку)Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам. Alexey Kudinov2 "читабельность" схемы БД значительно хуже. Тут без вариантов.Ну какая же это читабельность БД, если Вы на диаграмме сделаете связи от одной таблицы к пол сотни таблиц? Неужели одна связь от одной таблицы к одной другой менее наглядна? Alexey Kudinov3 поддержка целостности данных значительно хуже. Я бы сказал труднее. Опять же не известно, что будет быстрее, контроль всех связей, установленных путем констрейнов, или работа одного умного триггера. Готов поспорить на пиво, что триггер сделаю более раактивным, чем будут выполняться проверки пол сотни консрейнов штаными средствами. Alexey Kudinov4 реализация редактирования и добавления справочников лучше/проще.(что увеличивает опасность превращения базы в выгребную яму, как тут уже было сказано. Кроме того я не понимаю зачем для единого редактора справочников (например) они все должны быть в одной таблице)В выгребную яму можно превратить какую угодно базу. А вот на счет общей итерфейсной части, работающей со всеми справочниками, так думаю, что для этого не обязательно все справочники хранить в одной таблице. Можно придумать структуру, содержащую одтдельные таблицы для каждого справочника, и описательную часть справочников, используемую интерфейсным модулем для работы со справочниками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 19:39 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
>> Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам. При создании плана запроса оптимизатор использует статистику. Как вы думаете, когда оптимизация будет более существенной, когда у нас одна таблица (на которую все ссылаются), или когда у нас 10 таблиц и на каждой собрана статистика? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 10:41 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
>>Ну какая же это читабельность БД, если Вы на диаграмме сделаете связи от одной таблицы к пол сотни таблиц? Неужели одна связь от одной таблицы к одной другой менее наглядна? Можно вообще просто поступить. Создать в базе одну таблицу и давайте ее саму на себя по сто раз джойнить. Придет человек со стороны и, как вы думаете он быстро разберется в вашей бизнеслогике? В структуре?... Сильно сомневаюсь однако!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 10:44 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
>> А вот на счет общей итерфейсной части, работающей со всеми справочниками Трудно что-ли параметризировать форму? Передавать имя таблички? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 10:46 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
>>Я бы сказал труднее. Опять же не известно, что будет быстрее, контроль всех связей, установленных путем констрейнов, или работа одного умного триггера. Готов поспорить на пиво, что триггер сделаю более раактивным, чем будут выполняться проверки пол сотни консрейнов штаными средствами. Боже мой... какая чушь... ((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 10:51 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
gardenman>> Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам. При создании плана запроса оптимизатор использует статистику. Как вы думаете, когда оптимизация будет более существенной, когда у нас одна таблица (на которую все ссылаются), или когда у нас 10 таблиц и на каждой собрана статистика? думать бесполезно, тестировать надо. Или вы знаете работу оптимизатора? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 11:36 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
gardenman>> А вот на счет общей итерфейсной части, работающей со всеми справочниками Трудно что-ли параметризировать форму? Передавать имя таблички? тогда вы не сможете использовать фильтр набора записей - что значительно быстрее работает "перезагрузки" морды на другую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 11:39 |
|
||
|
Производительность при использовании единой таблицы для справочников
|
|||
|---|---|---|---|
|
#18+
Petro123 gardenman>> Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам. При создании плана запроса оптимизатор использует статистику. Как вы думаете, когда оптимизация будет более существенной, когда у нас одна таблица (на которую все ссылаются), или когда у нас 10 таблиц и на каждой собрана статистика? думать бесполезно, тестировать надо. Или вы знаете работу оптимизатора? Такие параметры как селективность, кардинальность, вам знакомы? Вам изветсно рапределение значений колонки в таблице? Вы знавете зачем нужны гистограммы? Это все описано в документации на СУБД которую вы юзаете. Между прочим подходы у всех к этому вопросу приблизительно одинаковые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 11:41 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33735209&tid=1545109]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
155ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 481ms |

| 0 / 0 |
