ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Производительность при использовании единой таблицы для справочников
25 сообщений из 106, страница 1 из 5
  1  все
Производительность при использовании единой таблицы для справочников
    #33731797
Sidorov Anton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sidorov Anton
Гость
Добрый день

Сейчас занимаемся проектированием БД. И поступило предложение организовать все справочники в одной таблице.
структура такая:
pk-ключ,nspr-номер справочника,nv-номер значения,v-значение

Как вы считаете что будет в плане производительности лучше:
использовать 10 справочников каждой в своей таблице или же организовать 1 таблицу со значениями всех справочников?
...
Рейтинг: 0 / 0
17.05.2006, 10:47
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33731803
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Будут накладки в плане использования ссылочной целостности.
...
Рейтинг: 0 / 0
17.05.2006, 10:48
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33731843
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Тут конечно вопрос более глубокий: производительности кого?

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

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

НО писать все программисты должны очень аккуратно: уж пару раз столкнетесь с "Будут накладки в плане использования ссылочной целостности" copiright gardenman.

Ну а если про производительность системы:надо много думать и смотреть,какие нужны отчеты,какая бизнес-логика. МОжет быть этих справочников будет 5 штук и отчетов по ним нет.

P.S. Есть третий вариант справочников в одной таблице - добавляются новые столбцы,соответствующие новым справочникам,а не тип значения.
...
Рейтинг: 0 / 0
17.05.2006, 11:01
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33731860
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
Sidorov Anton wrote:
поискать по форуму по словам "тенцер" или "EAV" - жевалось пережевывалось.

а для "Будут накладки в плане использования ссылочной целостности" -
после записи в справочник приходится вызывать процедуру проверки
структурной целостности элемента справочника, потому как накладки таки
имели место быть.

зато обычные кодеры лепят справочники с полным функционалом на 1-2-3.
Вот только ядро должно быть полность отлаженным и внушать доверие.


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
17.05.2006, 11:05
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33731871
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>> чуть быстрее при разработке вариант с одной таблицей
Ну очень сомнительное утверждение. Особенно когда дойдет до сопросождения и поддержки этой самой пресловутой "ссылочной целостности"
А генерить формы автоматом для разных справочников - это просто. Зря разве столько силбыло вложено в OOП?
Только умояляю, не надо делать справочников типа:
0 Нет No
1 Да Yes
NULL Не знаю Not defined
а то имеются и такие кадры
...
Рейтинг: 0 / 0
17.05.2006, 11:07
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33732115
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
locky
после записи в справочник приходится вызывать процедуру проверки
структурной целостности элемента справочника, потому как накладки таки
имели место быть.

не могли бы вы привести пример?

IMHO
Я так понял особенности:
EAV:
+
- хранение переменного количества атрибутов
- атрибуты развёрнуты по вертикали а не по полям (зависит от заказчика)
_

- нет связей по целостности данных на уровне БД
- для вывода шахматки приходится извращаться
- больше логики и кода переносится на БД и его язык
- проблемы в использовании визуального проектирования "морды" в bound-присоеденённом режиме к БД.
...
Рейтинг: 0 / 0
17.05.2006, 11:57
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33732303
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
To gardenman: под фразой ">> чуть быстрее при разработке вариант с одной таблицей " я имел в виду разработку именно интерфейса.Как не крути,но думать при делании интерфейса с одной таблицей надо много меньше,чем для нескольких. Причем быстрее только единовременно. ПРо целостность я и не говорил в данной фразе,про нее сказано дальше,что ее поддержка будет геморойнее.

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

Для одной таблицы с данными:
левую табличку формы строим на основе выборки из таблицы типов справочников (1 пробитый select без всяких условий (пусть не будет контроля доступа))
правую табличку делаем на основе выборки из таблицы значений справочников (1 пробитый селект с указанием типа справочника)

Для одной таблицы с данными:
левую табличку формы строим на основе выборки из таблицы справочников (типа из таблички с метаданные программы ) (1 пробитый select без всяких условий (пусть не будет контроля доступа))
правую табличку делаем на основе выборки из конкретной таблицы значений справочника (1 динамически построенный селект с указанием таблицы, из которой надо брать данные)
...
Рейтинг: 0 / 0
17.05.2006, 12:37
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33732391
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Чисто из опыта:
Всегда когда пытались изобрести велосипед, который и ездит, и летает и ползает по землей, получался велосипед, который все это делал плохо.
Если вообще получался... ((
...
Рейтинг: 0 / 0
17.05.2006, 12:57
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33732596
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
EAV не совсем в тему, хотя полей тоже три :). Скорее аналог - физики-юрики, только типов побольше.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE TABLE ObjType  (
  ObjType_ID Number PRIMARY KEY,
  ObjType_Name VARCHAR2( 100 ));
/
CREATE TABLE Object  (
  Object_ID  Number PRIMARY KEY,
  ObjType_ID Number NOT NULL REFERENCES ObjType(ObjType_ID),
  Object_Code VARCHAR2( 20 ),
  Object_Name VARCHAR2( 100 ) );
/
ALTER TABLE Object ADD  CONSTRAINT Object_U01 UNIQUE ( Object_ID, ObjType_ID);
/
ALTER TABLE Object ADD  CONSTRAINT Object_U02 UNIQUE ( ObjType_ID, Object_Code );
/

Использование с жестким контролем типа объекта
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
CREATE TABLE SomeTable (
    id NUMBER,
    Object_1_ID Number,
    ObjType_1_ID Number
);
/
ALTER TABLE SomeTable
ADD CONSTRAINT SomeTable_FK01
  FOREIGN KEY (Object_1_ID ,ObjType_1_ID)  REFERENCES Object ( Object_ID, ObjType_ID)
...
Рейтинг: 0 / 0
17.05.2006, 14:02
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33732607
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
gardenmanЧисто из опыта:
Всегда когда пытались изобрести велосипед, который и ездит, и летает и ползает по землей, получался велосипед, который все это делал плохо.
Если вообще получался... ((Но если повезет - получится мобильник с камерой и проч. и проч., который даже звонит.:).
...
Рейтинг: 0 / 0
17.05.2006, 14:05
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33733584
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> поступило предложение организовать все справочники в одной таблице

Откуда поступило, если не секрет? ;)

> структура такая

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

Слабо представляется, как Вы это умудритесь втиснуть в одну таблицу.
...
Рейтинг: 0 / 0
17.05.2006, 18:00
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33733767
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
guest_20040621Слабо представляется, как Вы это умудритесь втиснуть в одну таблицу.Ну, во-первых часто есть определенный набор справочников где кроме наименования ничего и не требуется. К тому же и меняются они редко. Первая мысль про обобщенный справочник обычно отсюда и возникает. Но здесь по опыту большого выигрыша нет. Единственно, создание нового справочника пользователем не требует DDL, что DBA всегда в радость.

Во-вторых, как с договорами -- физиками/юриками возникает необходимость в ссылках на заранее неизвестный тип объекта. Вот тут оно полезно обобщить все эти объекты в единый каталог, даже если типы объектов сильно разные и соответственно остаются разные таблицы для типов.
...
Рейтинг: 0 / 0
17.05.2006, 18:56
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734063
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Ну, во-первых часто есть определенный набор справочников где кроме
> наименования ничего и не требуется.

Конечно, есть. Только чего их обсуждать? - тривиальнейший частный случай.

> создание нового справочника пользователем не требует DDL, что DBA всегда в радость.

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

> как с договорами -- физиками/юриками

Imho ничего похожего.

> возникает необходимость в ссылках на заранее неизвестный тип объекта

Вас пример не затруднит привести?

> полезно обобщить все эти объекты в единый каталог

Т. е. Вы полагаете, что все справочнике с требованиями, перечисленными в [2675977], можно разместить в одной плоской таблице? ;)
...
Рейтинг: 0 / 0
17.05.2006, 22:22
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734565
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>Видите ли, я немного иначе отношусь к содержимому базы данных: это не выгребная яма
Поддерживаю полностью
...
Рейтинг: 0 / 0
18.05.2006, 10:02
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734634
Sidorov Anton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sidorov Anton
Гость
guest_20040621> поступило предложение организовать все справочники в одной таблице

Откуда поступило, если не секрет? ;)

> структура такая

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

Слабо представляется, как Вы это умудритесь втиснуть в одну таблицу.

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

ваша структура на мой взгляд подходит для математических систем.
...
Рейтинг: 0 / 0
18.05.2006, 10:22
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734644
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
> я считаю что реализация на одной таблице проще.
Флаг в руки и барабан на шею
...
Рейтинг: 0 / 0
18.05.2006, 10:25
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734701
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
guest_20040621 Справочники - я надеюсь, мы одно и то же под этим понимаем - как правило, имеют вполне себе конкретное происхождение; более того, их количество для предметной области, как правило, конечно . Так что т. н. "однотабличная" структура - в общем случае банальная ошибка проектирования.
как тогда расценивать перечислимые характеристики какого либа объекта, которые расширяются в процессе эксплуатации.
Наверно это достаточно распространённый случай:

Высота (высокий, низкий)
Глубина (глубокий, ооочень глубокий)
Бугорки (есть, нет)

Это ведь справочники?

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
18.05.2006, 10:42
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734706
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
guest_20040621> Ну, во-первых часто есть определенный набор справочников где кроме
> наименования ничего и не требуется.

Конечно, есть. Только чего их обсуждать? - тривиальнейший частный случай.
и я про тоже.
2 автор
--
Производительностью рулят фичи СУБД. Партиционирование, индексы и проч.
guest_20040621
> как с договорами -- физиками/юриками

Imho ничего похожего.

> возникает необходимость в ссылках на заранее неизвестный тип объекта

Вас пример не затруднит привести?
Э.. так это и был пример, так ничего он не похож на что?
Другой пример: средство связи от почтового адреса (разного в разных странах кстати) до URL. guest_20040621> полезно обобщить все эти объекты в единый каталог

Т. е. Вы полагаете, что все справочнике с требованиями, перечисленными в [2675977], можно разместить в одной плоской таблице? ;)
_Внимательно_: ModelRи соответственно остаются разные таблицы для типов.
...
Рейтинг: 0 / 0
18.05.2006, 10:43
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734712
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Petro123 guest_20040621 Справочники - я надеюсь, мы одно и то же под этим понимаем - как правило, имеют вполне себе конкретное происхождение; более того, их количество для предметной области, как правило, конечно . Так что т. н. "однотабличная" структура - в общем случае банальная ошибка проектирования.
как тогда расценивать перечислимые характеристики какого либа объекта, которые расширяются в процессе эксплуатации.
Наверно это достаточно распространённый случай:

Высота (высокий, низкий)
Глубина (глубокий, ооочень глубокий)
Бугорки (есть, нет)

Это ведь справочники?

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

За такие "справочники" пинал бы "проектировщика" пока не сломал ноги...
...
Рейтинг: 0 / 0
18.05.2006, 10:45
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734735
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
gardenman>Видите ли, я немного иначе отношусь к содержимому базы данных: это не выгребная яма
Поддерживаю полностьюВерно. Но к людям нужно относится еще лучше. А их потребность по ходу эксплуатации уточнить классификацию, ввести еще один признак типа Высота (высокий, низкий)
Глубина (глубокий, ооочень глубокий)
Бугорки (есть, нет)вполне реальна.
gardenmanЗа такие "справочники" пинал бы "проектировщика" пока не сломал ноги...
И затем?
...
Рейтинг: 0 / 0
18.05.2006, 10:51
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734742
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Sidorov AntonСейчас занимаемся проектированием БД. И поступило предложение организовать все справочники в одной таблице.
структура такая: pk-ключ,nspr-номер справочника,nv-номер значения,v-значение
Лет тринадцать назад, когда я пришел работать на Clipper в давно уже не существующую компанию, там эксплуатировалось такое решение, и в случае Clipper давало некоторые преимущества.

Чуть позже, когда на следующей работе я спросил "а почему не сделать так?", мне просто и наглядно показали, что в случае нормальных СУБД и нормальных инструментов это.... изврат на пустом месте, назовем так. И с тех пор я не встречал информации, которая опровергла бы эту точку зрения.
...
Рейтинг: 0 / 0
18.05.2006, 10:53
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734750
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
IMHO
модель EAV - не на пустом месте появилась, а от лени программистов делать на каждый чих отдельную таблицу.

2. У меня есть один такой проект от которого отказался заказчик из-за того что в БД 100 таблиц - справочников к одной главной таблице (ROT)
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
18.05.2006, 10:56
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734821
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Petro123
1) Если у вас таблицы-справочники такие , как писал я, - то понятно...
2) Количество таблиц в модели - не причина отказа. Посмотрите на People Soft (15000 таблиц, 15000 вьюх) - не скажу что я восхищен, однако...
Нужно думать всегда над тем, как упростить модель.
Вот это:
Код: plaintext
1.
2.
3.
4.
5.
create table person (
   ...
   gender char( 1 ) check (gender in ('M','F'))
   ...
)
Выглядит гораздо проще и привлекательней чем вот это
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create table gender (
    gender  smallint,
    gender_txt char( 30 )
)
alter table gender add constraint primary key ...
create table person (
   ...
   gender char( 1 ) not null
   ...
)
alter table person add constraint foreign key ...

Главное - упростить работу с с базой данных. Упростить создание приложений.
...
Рейтинг: 0 / 0
18.05.2006, 11:13
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734948
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
gardenmanPetro123
1) Если у вас таблицы-справочники такие , как писал я, - то понятно...
======= "мужчина-жен." нет, а вот таких "перечислимых" полно.

2) Количество таблиц в модели - не причина отказа. Посмотрите на People Soft (15000 таблиц, 15000 вьюх) - не скажу что я восхищен, однако...
=========== конечно это не один показатель, но ОН (количество строк кода/таблиц/движений_кухарки) тоже учитывается.

Нужно думать всегда над тем, как упростить модель.
Вот это:
Код: plaintext
1.
create table person (
========== не очень могу читать не визуально а с кода, но с интересом изучу
Главное - упростить работу с с базой данных. Упростить создание приложений.
========== согласен! А то клиент "валит" на сервер, а сервер на клиента )

"Если ты сервер - не суетись под клиентом" (с) ))))
...
Рейтинг: 0 / 0
18.05.2006, 11:43
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33734965
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
По теме.

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

Скорость здесь последний фактор - решается административными мерами.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
18.05.2006, 11:48
| Ответить | Цитировать | Написать  
25 сообщений из 106, страница 1 из 5
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Производительность при использовании единой таблицы для справочников
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=33734750&tid=1545109]:
 0ms
get settings:
 6ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 49ms
get topic data:
 6ms
get forum data:
 1ms
get page messages:
 37ms
get tp. blocked users:
 1ms
others: 194ms
total:  307ms
созд. / загр.: 307ms
x
x
Закрыть


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