ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Производительность при использовании единой таблицы для справочников
106 сообщений из 106, показаны все 5 страниц
  все  
Производительность при использовании единой таблицы для справочников
    #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
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735209
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Petro1232. У меня есть один такой проект от которого отказался заказчик из-за того что в БД 100 таблиц - справочников к одной главной таблице (ROT)
Хм. Заказчики бывают и более талантливыми идиотами - но что из этого следует?

С другой стороны, в одном проекте коллеги сделали совершенно замечательную фигню. Им показалось, что справочники "слишком маленькие", и поэтому они сделали справочники "два в одном" - то есть вместо справочников А и Б сделали справочники вида А cross join Б. Как Вы догадываетесь, работать с этим было офигенно удобно :)
...
Рейтинг: 0 / 0
18.05.2006, 12:39
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735287
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
softwarer"слишком маленькие"
я про такой критерий не говорил. Заказчик выбрал не ROT и это его право.
Моё IMHO по теме я сказал:
/topic/294156&pg=1#2678055
...
Рейтинг: 0 / 0
18.05.2006, 12:56
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735304
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> ваша структура на мой взгляд подходит для математических систем

Если бы. ;) На самом деле это очень простой вариант реализации справочника.
...
Рейтинг: 0 / 0
18.05.2006, 12:59
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735324
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Другой пример: средство связи от почтового адреса
> (разного в разных странах кстати) до URL

Великолепный пример. Давайте чуть подробнее на нем остановимся. Если я правильно понимаю, Вы полагаете, что целесообразно иметь некий универсальный справочник под именем "средства связи"?

> _Внимательно_:

Извините, пропустил фразу.
...
Рейтинг: 0 / 0
18.05.2006, 13:02
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735350
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Высота (высокий, низкий)
> Глубина (глубокий, ооочень глубокий)
> Бугорки (есть, нет)

;)))

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

А сами-то Вы как думаете? ;))
...
Рейтинг: 0 / 0
18.05.2006, 13:07
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735351
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Petro123Заказчик выбрал не ROT и это его право.
Безусловно. Я к тому, что "мнение заказчика" - нисколько не аргумент в разговоре о технической стороне дела. Такой аргумент мог бы быть уместен в беседе о "продаваемости" того или иного варианта решения. К сожалению, зависимость между этими двумя факторами... весьма нелинейна, назовем так.
...
Рейтинг: 0 / 0
18.05.2006, 13:07
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735379
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> потребность по ходу эксплуатации уточнить классификацию

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

> вполне реальна

Imho информативность приведенных характеристик стремится к нулю.
...
Рейтинг: 0 / 0
18.05.2006, 13:13
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735569
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
Petro123 wrote:
> locky
>
> после записи в справочник приходится вызывать процедуру проверки
> структурной целостности элемента справочника, потому как накладки таки
> имели место быть.
>
> не могли бы вы привести пример?
Поскольку все референсы идут к одной и той же таблице, содержащие
экземпляры разных объектов, запросто вместо счета можно сослаться по
подразделение. Я боролся путем процедуры доп. контроля при записи. Выше
люди показывали еще один оччень интересный способ (надо над этим подумать).

>
> *IMHO*
> Я так понял особенности:
> EAV:
> *+*
> - хранение переменного количества атрибутов
> - атрибуты развёрнуты по вертикали а не по полям (зависит от заказчика)
а это пофиг... хошь - так показывай, хошь - так...
на физическом то уровне всё равно - всё вертикально :-)

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

> - для вывода шахматки приходится извращаться
недопонил. при чем тут отображение данных к хранению? из 3НФ что, легче?

> - больше логики и кода переносится на БД и его язык
минус ли это? кому как.
> - проблемы в использовании визуального проектирования "морды" в
> bound-присоеденённом режиме к БД.
про "боунд" - не понил, а проблем в проектировании интерфейсов вроде как
не было - всё эдак ровненько пострижено, покрашено, единообразно...
Юзеров учить легче, опять таки.

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
18.05.2006, 13:55
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735716
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
locky
> - для вывода шахматки приходится извращаться
недопонил. при чем тут отображение данных к хранению? из 3НФ что, легче?

> bound-присоеденённом режиме к БД.
про "боунд" - не понил, а проблем в проектировании интерфейсов вроде как
не было - всё эдак ровненько пострижено, покрашено, единообразно...
Юзеров учить легче, опять таки.

1. всё-таки имеет значение при прочих равных условиях , т.к. если данные по горизонтали (в полях) и их нужно развернуть по вертикали (записях) на клиента, да ещё редактировать, то это не просто.
Если, например, характеристики товара динамические, то на клиенте их в поля выводить нет никакого смысла.

2. Много компонентов и клиентских библиотек сами формируют текст запроса UPDATE.... и заточены работать с "исторической" ROT схемой а не EAV и моделью Тенцера.
...
Рейтинг: 0 / 0
18.05.2006, 14:23
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735852
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PVP
Участник
Sidorov AntonДобрый день

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

Как вы считаете что будет в плане производительности лучше:
использовать 10 справочников каждой в своей таблице или же организовать 1 таблицу со значениями всех справочников?Я использую такую структуру. На производительности выборки данных это практически никак не сказывается. При использовании индексов, в которых первым полем идет код справочника, зана выборки ограничивается в таблице только множеством записей указанного справочника. Поэтому, это еще не извествно, как будет происходит выборка быстрее, каогда у вас несколько join к одной таблице с разными условиями, или тоже, но к разным таблицам.

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

На счет скорости программирования - много раз убедился в том, что это было хорошое решение. Справочники добавляются на лету, без остановки системы, без необходимости измень структуру базы данных (за редким исключением).
В интерфейсной части со всеми справочниками работают две-три формы. Легко описывать состав справочников, легко ими управлять. Это очень важно при сопровождении тем программистам, которые не являеются разработчиками. Объясняя им показываешь - вот одна таблица, вот два индекса, вот одно поле код справочника - включай в запросы. А как бы объявнял, когда были бы десятки таблиц, не знаю.

ИМХО. Старшее поколение правильно предлагает. Недостаков нет, одни преимущества.
...
Рейтинг: 0 / 0
18.05.2006, 14:53
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735937
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
PVP не могли бы вы рпивести скрин управления и модификации такими "справочниками в одном флаконе". У нас это называется классификатор, и он может менятся - переподключаться пользователем.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
18.05.2006, 15:14
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735950
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PVP
Участник
Petro123 PVP не могли бы вы рпивести скрин управления и модификации такими "справочниками в одном флаконе". У нас это называется классификатор, и он может менятся - переподключаться пользователем.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!Счас попробую.
...
Рейтинг: 0 / 0
18.05.2006, 15:17
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735971
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PVP
Участник
http://www.softbas.com.ua/forum/index.php?act=module&module=gallery&cmd=si&img=22 - это окно для настройки справочников
...
Рейтинг: 0 / 0
18.05.2006, 15:20
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33735995
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PVP
Участник
http://www.softbas.com.ua/forum/index.php?act=module&module=gallery&cmd=si&img=23 - общий ввод данных в справочники
...
Рейтинг: 0 / 0
18.05.2006, 15:24
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33736055
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PVP
Участник
Petro123У нас это называется классификатор, и он может менятся - переподключаться пользователем.Ну, наверное "подключаться пользователями" - это перебор. Все мои попытки и эксперименты моих знакомых дать возможность девушкам-пользователям, а особенно продвинутым спецам-пользователям добираться в те места, где подключаются справочники, заканчивались тем, что отключали им вообще доступ к возможности настроек.

Подключение справочников - это по сути настройка структуры базы данных, а именно связей между наборами данных. Если бы это были отдельные таблицы, то я сказал бы связей между таблицами, констрейнов. И к этой работе лучше пользователей не подпускать. Пусть этим программисты занимаются.
...
Рейтинг: 0 / 0
18.05.2006, 15:34
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33736078
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
guest_20040621> Другой пример: средство связи от почтового адреса
> (разного в разных странах кстати) до URL

Великолепный пример. Давайте чуть подробнее на нем остановимся. Если я правильно понимаю, Вы полагаете, что целесообразно иметь некий универсальный справочник под именем "средства связи"?
Давайте. Открыл тему т.к. в единую таблицу точно не укладывается.
...
Рейтинг: 0 / 0
18.05.2006, 15:45
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33736741
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
PVPИМХО. Старшее поколение правильно предлагает. Недостаков нет, одни преимущества. Как вы категоричны....
Новым разработикам вы тоже поясняете, что в таблице A, в колонке B могут быть только 3 значения потому что так в триггере написано ?

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

2 "читабельность" схемы БД значительно хуже. Тут без вариантов.

3 поддержка целостности данных значительно хуже.

4 реализация редактирования и добавления справочников лучше/проще.
(что увеличивает опасность превращения базы в выгребную яму, как тут уже было сказано. Кроме того я не понимаю зачем для единого редактора справочников (например) они все должны быть в одной таблице)
...
Рейтинг: 0 / 0
18.05.2006, 18:30
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33736886
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PVP
Участник
Alexey Kudinov PVPИМХО. Старшее поколение правильно предлагает. Недостаков нет, одни преимущества. Как вы категоричны....
Новым разработикам вы тоже поясняете, что в таблице A, в колонке B могут быть только 3 значения потому что так в триггере написано ?Ну я же сделал приставку "Имхо", это смягчает мою вину. К тому же, почему обязательно в триггере? В систему настройки справочника добавьте соответствующее свойство поля, введите это ограничение, и пусть триггер считывает его из свойств и применяет.

Alexey Kudinov1 Производительность хуже, конечно, но не так чтобы очень. (ввиду отсутствия каких-либо разъяснений у автора треда, приходится давать такую умозрительную оценку)Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам.

Alexey Kudinov2 "читабельность" схемы БД значительно хуже. Тут без вариантов.Ну какая же это читабельность БД, если Вы на диаграмме сделаете связи от одной таблицы к пол сотни таблиц? Неужели одна связь от одной таблицы к одной другой менее наглядна?

Alexey Kudinov3 поддержка целостности данных значительно хуже. Я бы сказал труднее. Опять же не известно, что будет быстрее, контроль всех связей, установленных путем констрейнов, или работа одного умного триггера. Готов поспорить на пиво, что триггер сделаю более раактивным, чем будут выполняться проверки пол сотни консрейнов штаными средствами.

Alexey Kudinov4 реализация редактирования и добавления справочников лучше/проще.(что увеличивает опасность превращения базы в выгребную яму, как тут уже было сказано. Кроме того я не понимаю зачем для единого редактора справочников (например) они все должны быть в одной таблице)В выгребную яму можно превратить какую угодно базу. А вот на счет общей итерфейсной части, работающей со всеми справочниками, так думаю, что для этого не обязательно все справочники хранить в одной таблице. Можно придумать структуру, содержащую одтдельные таблицы для каждого справочника, и описательную часть справочников, используемую интерфейсным модулем для работы со справочниками.
...
Рейтинг: 0 / 0
18.05.2006, 19:39
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33737753
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>> Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам.

При создании плана запроса оптимизатор использует статистику.
Как вы думаете, когда оптимизация будет более существенной, когда у нас одна таблица (на которую все ссылаются), или когда у нас 10 таблиц и на каждой собрана статистика?
...
Рейтинг: 0 / 0
19.05.2006, 10:41
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33737766
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>>Ну какая же это читабельность БД, если Вы на диаграмме сделаете связи от одной таблицы к пол сотни таблиц? Неужели одна связь от одной таблицы к одной другой менее наглядна?

Можно вообще просто поступить. Создать в базе одну таблицу и давайте ее саму на себя по сто раз джойнить.

Придет человек со стороны и, как вы думаете он быстро разберется в вашей бизнеслогике? В структуре?... Сильно сомневаюсь однако!)
...
Рейтинг: 0 / 0
19.05.2006, 10:44
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33737774
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>> А вот на счет общей итерфейсной части, работающей со всеми справочниками
Трудно что-ли параметризировать форму? Передавать имя таблички?
...
Рейтинг: 0 / 0
19.05.2006, 10:46
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33737790
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>>Я бы сказал труднее. Опять же не известно, что будет быстрее, контроль всех связей, установленных путем констрейнов, или работа одного умного триггера. Готов поспорить на пиво, что триггер сделаю более раактивным, чем будут выполняться проверки пол сотни консрейнов штаными средствами.

Боже мой... какая чушь... (((
...
Рейтинг: 0 / 0
19.05.2006, 10:51
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33738005
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
gardenman>> Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам.

При создании плана запроса оптимизатор использует статистику.
Как вы думаете, когда оптимизация будет более существенной, когда у нас одна таблица (на которую все ссылаются), или когда у нас 10 таблиц и на каждой собрана статистика?
думать бесполезно, тестировать надо. Или вы знаете работу оптимизатора?
...
Рейтинг: 0 / 0
19.05.2006, 11:36
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33738015
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
gardenman>> А вот на счет общей итерфейсной части, работающей со всеми справочниками
Трудно что-ли параметризировать форму? Передавать имя таблички?
тогда вы не сможете использовать фильтр набора записей - что значительно быстрее работает "перезагрузки" морды на другую таблицу.
...
Рейтинг: 0 / 0
19.05.2006, 11:39
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33738026
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Petro123 gardenman>> Это надо доказать еще, какой запрос будет быстрее, если сделать 10 штук join к одной таблице или эти же 10 к 10 таблицам.

При создании плана запроса оптимизатор использует статистику.
Как вы думаете, когда оптимизация будет более существенной, когда у нас одна таблица (на которую все ссылаются), или когда у нас 10 таблиц и на каждой собрана статистика?
думать бесполезно, тестировать надо. Или вы знаете работу оптимизатора?

Такие параметры как селективность, кардинальность, вам знакомы?
Вам изветсно рапределение значений колонки в таблице?
Вы знавете зачем нужны гистограммы?
Это все описано в документации на СУБД которую вы юзаете. Между прочим подходы у всех к этому вопросу приблизительно одинаковые.
...
Рейтинг: 0 / 0
19.05.2006, 11:41
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33738136
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
gardenman
Я более практик, чем теоретик (если это Вас интересует).
Иногда полезно с небес на землю спуститься (чтоб не исследовать работу оптимизатора для всех БД вместе взятых).

"Для определения качества приготовленной яичницы - необязательно уметь нести яйца" - (с)
Я только за то, что:
Не стоит строить архитектуру на "приблизительных подходах". ______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
19.05.2006, 12:08
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33738155
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
2 Petro123
Чтож, уважаю Вашу точку зрения. Вам с Вашего рабочего места виднее.
...
Рейтинг: 0 / 0
19.05.2006, 12:12
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33744500
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ModelR
Не могли бы Вы прояснить Ваш текст в более понятном виде (никак не уясню суть без голых данных-примеров)
http://www.sql.ru/forum/actualpost.aspx?bid=36&tid=294156&mid=0&p=1#2674302

ObjType
70 ???71 ???100 ???

Object
13 100 ??? Phone14 100 ??? Phone

SomeTable
1 13 702 14 71
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
23.05.2006, 10:55
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33745036
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Petro123 ModelR
Не могли бы Вы прояснить Ваш текст в более понятном виде (никак не уясню суть без голых данных-примеров)
http://www.sql.ru/forum/actualpost.aspx?bid=36&tid=294156&mid=0&p=1#2674302 Без проблем. Ближе к теме топика:
Например, в таблице SomeTable атрибут 1 "основное качество" может быть ровно одним из приведенных выше перечислений Бугорки, Глубина, Высота .

ObjType = Справочник
ObjType_IDObjType_Name 70 Бугорки71 Глубина100 Высота

Object = Позиция справочника
Object_ID ObjType_ID Object_CodeObject_Name13 100 высокий виден из далека14 100 низкий 15 71 ооочень_глубокий дна не достать

SomeTable
Id Attr1_ID Attr1_TypeId more attributes1 13 1002 14 1003 15 71
...
Рейтинг: 0 / 0
23.05.2006, 12:44
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33878831
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
ModelR Petro123 ModelR
Не могли бы Вы прояснить Ваш текст в более понятном виде (никак не уясню суть без голых данных-примеров)
http://www.sql.ru/forum/actualpost.aspx?bid=36&tid=294156&mid=0&p=1#2674302 Без проблем. Ближе к теме топика:
Например, в таблице SomeTable атрибут 1 "основное качество" может быть ровно одним из приведенных выше перечислений Бугорки, Глубина, Высота .

ObjType = Справочник
ObjType_IDObjType_Name 70 Бугорки71 Глубина100 Высота

Object = Позиция справочника
Object_ID ObjType_ID Object_CodeObject_Name13 100 высокий виден из далека14 100 низкий 15 71 ооочень_глубокий дна не достать

SomeTable
Id Attr1_ID Attr1_TypeId more attributes1 13 1002 14 1003 15 71
А теперь вопрос: что с этим рациональнее всего сделать, если Бугорки - Есть/Нет, Высота измеряется в метрах, а вместо Глубины Цвет (ну пусть для примера целочисленный).
...
Рейтинг: 0 / 0
26.07.2006, 11:34
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33880088
sqllex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sqllex
Участник
Использование 1-го справочника отрицательно скажется на отчетах (скорость), где фигурируют данные из нескольких справочников.
Сервер БД может подтормаживать при плотной работе пользователей числом больше 3. Особенно в режиме редактирования этих самых справочников.
...
Рейтинг: 0 / 0
26.07.2006, 15:55
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33880135
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Область применения достаточно узкая, но реальная: множесто простых и коротких (память на данные сравнима с памятью на словарь данных для таблицы) справочников с однотипными значениями. Справочники создаются достаточно часто, но после создания их содержание меняется редко.
...
Рейтинг: 0 / 0
26.07.2006, 16:09
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33880201
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
sqllexИспользование 1-го справочника отрицательно скажется на отчетах (скорость), где фигурируют данные из нескольких справочников.
Сервер БД может подтормаживать при плотной работе пользователей числом больше 3. Особенно в режиме редактирования этих самых справочников.
неужели?
Сервер предназначен для МНОГОПОЛЬЗОВАТЕЛЬСКОЙ работы. Если он "подтормаживает" при > 3х пользователей .

Вот вы читаете этот пост и его редактируют другие сколько_пользователей ?
...
Рейтинг: 0 / 0
26.07.2006, 16:27
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33880837
sqllex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sqllex
Участник
Угу, представьте себе, тормозил именно сервер БД при выполнении ХП. Кол-во работников, которые работали в системе на вводе данных было аж 5 человек.
Работали плотно как раз с этим справочником и документами, которые связаны были с несколькими справочниками, физически помещенными в один суперсправочник.
Исходя из этого я и написал "больше 3". Хотя специально я не проверял, как повела бы себя система с 4-мя пользователми, но, думаю, большой разницы не было бы.
...
Рейтинг: 0 / 0
26.07.2006, 21:20
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33881234
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bas
Участник
2 sqllex

Кривизна той реализации или производительность сервера СУБД не дает вам право делать такие выводы. У нас например идет поток в 2000 сложных транзакций в сек. и ничего обрабатывается ....
...
Рейтинг: 0 / 0
27.07.2006, 09:41
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33885567
sqllex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sqllex
Участник
bas2 sqllex
Кривизна той реализации или производительность сервера СУБД не дает вам право делать такие выводы. У нас например идет поток в 2000 сложных транзакций в сек. и ничего обрабатывается ....
Кривизна реализации чего именно, можно уточнить?
Разделение справочников и соответсвующие изменения кода ХП на том же железе - получили отсутствие тормозов при одновременной работе (выполняли те же действия с этими же таблицами) 12 человек - ни одной жалобы.
Вывод (мой): кривая реализация именно хранения справочников все в одном. Изменили метод - проблема ушла.
...
Рейтинг: 0 / 0
28.07.2006, 15:19
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33886597
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
sqllexКривизна реализации чего именно, можно уточнить?
Разделение справочников и соответсвующие изменения кода ХП на том же железе - получили отсутствие тормозов при одновременной работе (выполняли те же действия с этими же таблицами) 12 человек - ни одной жалобы.
Вывод (мой): кривая реализация именно хранения справочников все в одном. Изменили метод - проблема ушла.
С кода ХП нужно было и начинать. Какая зависимость между количеством пользователей и хранением записей однотипных справочников в одной таблице? Единственная. Какая-то ХП (зачем она для справочника?) которая тормозила. Но не тема топика.
...
Рейтинг: 0 / 0
29.07.2006, 00:20
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33887094
gybson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gybson
Участник
Предлагаю назвать это не справочниками, а списками и не париться. Нормальное решение, когда необходимо в системе иметь кучу объектов типа "Ссылка-Наименование".
...
Рейтинг: 0 / 0
29.07.2006, 18:39
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33887859
sqllex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sqllex
Участник
iscrafm
С кода ХП нужно было и начинать. Какая зависимость между количеством пользователей и хранением записей однотипных справочников в одной таблице? Единственная. Какая-то ХП (зачем она для справочника?) которая тормозила. Но не тема топика.
Ага, конечно! Зачем вообще ХП для справочников? :)

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

Что касается изменения кода ХП, то обьясните мне, тугодуму, как можно было использовать старый код, если структура БД изменилась?
...
Рейтинг: 0 / 0
30.07.2006, 21:59
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33887885
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
sqllexАга, конечно! Зачем вообще ХП для справочников? :)

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

Что касается изменения кода ХП, то обьясните мне, тугодуму, как можно было использовать старый код, если структура БД изменилась?
целых 3 параграфа, а в чем смысл? Можете яснее изъясняться?
...
Рейтинг: 0 / 0
30.07.2006, 22:56
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33888292
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
sqllexМожет быть покажете на примерчике как написать ХП
ну хотя бы, написать так, чтобы сервер (его оптимизатор) при каждом запуске не менял план выполнения запроса . Для MS SQL Server есть куча способов, но это отдельная тема IMHO
...
Рейтинг: 0 / 0
31.07.2006, 10:15
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33888614
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
sqllexМожет быть покажете на примерчике как написать ХП для сабжевого справочника, которая делает выборку документов с участием нескольких справочников (у нас было максимум 7). Вот тогда и поговорим о ХП, которая в этих условиях не будет тормозить.

Что касается изменения кода ХП, то обьясните мне, тугодуму, как можно было использовать старый код, если структура БД изменилась? Petro123ну хотя бы, написать так, чтобы сервер (его оптимизатор) при каждом запуске не менял план выполнения запроса.
Ответ поразил, честно.

Petro123 - скажите, а при чем тут изменение плана ?
Вы полагаете, что если план не изменяется - производительность вырастет ?
...
Рейтинг: 0 / 0
31.07.2006, 11:39
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33889149
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
[quot Alexey Kudinov[/quot]
Вы полагаете, что если план не изменяется - производительность вырастет ?[/quot]
разумеется, примерно на 1 сек. (не требуется оптимизация + компилировать + сохранение в кэше). Если использовать в цикле, то время набегает ....
======
Статичный запрос всегда выполняется быстрее чем динамичный.
...
Рейтинг: 0 / 0
31.07.2006, 13:58
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33890356
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
Не забудьте про блокировки в одной таблице, они должны существенно усложнить одновременную работу с разными справочниками. Кстати, у меня есть мнение, что при работе с таблицей данных, ссылающейся на большое кол-во справочников в одной таблице (>10) иногда наблюдаются глюки оптимизатора.
Вопрос к уважаемым спецам.
Система хранит данные на пересечении справочников. Таблиц данных много. Справочников много. Скорость изменения справочников низкая (20-30 записей в день). Скорость изменения данных средняя (10 000 записей в день). Ссылочная целостность обязательна. Справочники имеют разный состав полей. НО, существуют (назовем так - недосправочники) это некоторые наборы строк из разных справочников. Часть полей в таблице данных должна состоять из значений строк РАЗНЫХ справочников, входящих в набор. Как реализовывать?
...
Рейтинг: 0 / 0
31.07.2006, 20:34
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33891024
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ЛеоНе Часть полей в таблице данных должна состоять из значений строк РАЗНЫХ справочников, входящих в набор. Как реализовывать?
вот это непонятно.

Простейший случай:
id_справочника_ФИО зарплата23 1350руб

справочник
id_справочника_ФИО ФИО23 Петров
...
Рейтинг: 0 / 0
01.08.2006, 10:19
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33891661
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Мои 5 копеек ;)

А каким образом документировать подобный набор справочников и связей?
Создание справочников на пром, тестовой и девелоперских базах? Инсерт скриптами?
Пользователь насоздовал справочников PK на пром.схеме, потом их синхронизировать с тестовой...?
Мне кааца, что описание системы будет страдать, для мелких систем возможно и пойдет, для крупных сложно поддерживать.
Совместная работа при BPM, CDM, PDM и т.п. тоже наверное будет не фонтан...
...
Рейтинг: 0 / 0
01.08.2006, 13:06
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33891691
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Гость1111
вы приведите пример проблемных справочников. Они ведь разные бывают. Ведь можно создать целую БД-справочников. А можно простейший случай:
БОЛЬШОЙ_справочник из мелких справочников (ДниНедели+КритическиеДни+УлицыГорода+.......)
...
Рейтинг: 0 / 0
01.08.2006, 13:16
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33891735
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Я скорее не про проблему справочников, а про то чем вы моделировать это дело будете, как документировать, как управлять изменениями?
Будете писать свой редактор моделей, метамоделей, cvs и т.п.? - удачи ;)
...
Рейтинг: 0 / 0
01.08.2006, 13:26
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33891897
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Гость1111Я скорее не про проблему справочников, а про то чем вы моделировать это дело будете, как документировать, как управлять изменениями?
Будете писать свой редактор моделей, метамоделей, cvs и т.п.? - удачи ;)
что сложного-то?
Справочники не создаёт пользователь.
При разработке 2 варианта:
1. Вы делаете Большую таблицу с постоянным числом справочников.
2. Вы делаете много таблиц с постоянным числом этих таблиц.

Всё остальное (конструкторы метаданных пользователем а-ля 1С) не для меня, этого форума, и этого уровня мЫшления. IMHO
...
Рейтинг: 0 / 0
01.08.2006, 14:03
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33891976
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
Petro123
Всё остальное (конструкторы метаданных пользователем а-ля 1С) не для меня, этого форума, и этого уровня мЫшления. IMHOВы имеете в виду способы, в которых количество таблиц не постоянно?..
...
Рейтинг: 0 / 0
01.08.2006, 14:18
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892031
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
На мой вопрос внимания не обратили. Мои 5 копеек.
Описываю свою ситуацию. Поскольку справочники могут быть разными (разное число полей и разные типы), продукт будет стоять у большого кол-ва заказчиков (они сами делают справочники), то и в случае одной таблицы и в случае многих потребуется система управления справочниками. Сложность ее в обоих случаях примерно одинакова. Наличие команд DDL не является принципиальной сложностью при наличии определенных прав доступа. Документирование ведется для абстрактных справочников. Зато ссылочная целостность в случае разных таблиц не позволит получить чужой справочник там, где не надо. В моем случае все осложнается ссылкой из одного поля на элементы из разных справочников. Один из вариантов - категоризация. Подскажите еще варианты.
...
Рейтинг: 0 / 0
01.08.2006, 14:32
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892037
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Petro123 Гость1111Я скорее не про проблему справочников, а про то чем вы моделировать это дело будете, как документировать, как управлять изменениями?
Будете писать свой редактор моделей, метамоделей, cvs и т.п.? - удачи ;)
что сложного-то?
Справочники не создаёт пользователь.
При разработке 2 варианта:
1. Вы делаете Большую таблицу с постоянным числом справочников.
2. Вы делаете много таблиц с постоянным числом этих таблиц.

Всё остальное (конструкторы метаданных пользователем а-ля 1С) не для меня, этого форума, и этого уровня мЫшления. IMHO

Можете привести какую-либо диаграмму, подготовленную, скажем, в Power Designer описывающую связи между Бугорки-соме табле?
Кроме того, при развитии системы если такое, конечно, планируется, думаю, будут проблемы с триггерами, представлениями и т.п. про целостность уже говорили...
...
Рейтинг: 0 / 0
01.08.2006, 14:33
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892055
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Dogen Petro123
Всё остальное (конструкторы метаданных пользователем а-ля 1С) не для меня, этого форума, и этого уровня мЫшления. IMHOВы имеете в виду способы, в которых количество таблиц не постоянно?..
да! Это программа-конструктор и БД-конструктор. Другой класс программ и ТЗ другое.
...
Рейтинг: 0 / 0
01.08.2006, 14:37
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892119
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
исходя из этого поста
Petro123
guest_20040621Справочники - я надеюсь, мы одно и то же под этим понимаем - как правило, имеют вполне себе конкретное происхождение; более того, их количество для предметной области, как правило, конечно. Так что т. н. "однотабличная" структура - в общем случае банальная ошибка проектирования.

как тогда расценивать перечислимые характеристики какого либа объекта, которые расширяются в процессе эксплуатации.
Наверно это достаточно распространённый случай:

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

Это ведь справочники?
у меня работает проект на справочника-классификаторе (хоть это не одно и то-же но близко)
можно сделать по таблице на - Бугорки Высота Глубина
можно по EAV (как у меня) -

Список_значений (тип 3 перечислимое)1 Бугорки 32 Высота 13 Глубина 1

Объекты2324

Значения23 1 1623 2 4
СправочникПеречислимых1 1 Высокие1 2 Низкие22 Тёплые22 Холодные______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
01.08.2006, 14:53
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892160
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Лео(они сами делают справочники), то и в случае одной таблицы и в случае многих потребуется система управления справочниками. Сложность ее в обоих случаях примерно одинакова. Наличие команд DDL не является принципиальной сложностью при наличии определенных прав доступа. Документирование ведется для абстрактных справочников. Зато ссылочная целостность в случае разных таблиц не позволит получить чужой справочник там, где не надо. В моем случае все осложнается ссылкой из одного поля на элементы из разных справочников. Один из вариантов - категоризация. Подскажите еще варианты.
в вашем случае - клиент меняет структуру БД и создаёт таблицы
в моём - добавляет записи! Т.е. то на что и должен работать сервер. Это несоизмеримо!
Потом у меня просто количество атрибутов у объектов может быть 200-300. Если создавать 200-300 таблиц на клиенте пользователем это изврат.
...
Рейтинг: 0 / 0
01.08.2006, 15:00
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892216
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Petro123 Лео(они сами делают справочники), то и в случае одной таблицы и в случае многих потребуется система управления справочниками. Сложность ее в обоих случаях примерно одинакова. Наличие команд DDL не является принципиальной сложностью при наличии определенных прав доступа. Документирование ведется для абстрактных справочников. Зато ссылочная целостность в случае разных таблиц не позволит получить чужой справочник там, где не надо. В моем случае все осложнается ссылкой из одного поля на элементы из разных справочников. Один из вариантов - категоризация. Подскажите еще варианты.
в вашем случае - клиент меняет структуру БД и создаёт таблицы
в моём - добавляет записи! Т.е. то на что и должен работать сервер. Это несоизмеримо!
Потом у меня просто количество атрибутов у объектов может быть 200-300. Если создавать 200-300 таблиц на клиенте пользователем это изврат.

Клиент не должен сам создавать ни объекты, ни справочники.
Структура БД, состав документов, форм, и приложения должна быть определена на этапе проектирования.
...
Рейтинг: 0 / 0
01.08.2006, 15:10
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892269
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Гость1111 Petro123 Лео(они сами делают справочники), то и в случае одной таблицы и в случае многих потребуется система управления справочниками. Сложность ее в обоих случаях примерно одинакова. Наличие команд DDL не является принципиальной сложностью при наличии определенных прав доступа. Документирование ведется для абстрактных справочников. Зато ссылочная целостность в случае разных таблиц не позволит получить чужой справочник там, где не надо. В моем случае все осложнается ссылкой из одного поля на элементы из разных справочников. Один из вариантов - категоризация. Подскажите еще варианты.
в вашем случае - клиент меняет структуру БД и создаёт таблицы
в моём - добавляет записи! Т.е. то на что и должен работать сервер. Это несоизмеримо!
Потом у меня просто количество атрибутов у объектов может быть 200-300. Если создавать 200-300 таблиц на клиенте пользователем это изврат.

Клиент не должен сам создавать ни объекты, ни справочники.
Структура БД, состав документов, форм, и приложения должна быть определена на этапе проектирования.
я бы сказал, если заказчик не просит-платит за "конструктор".
ЗЫ.
посмотри рядом топик "Понятие Рабочее место" - не всё однозначно.
...
Рейтинг: 0 / 0
01.08.2006, 15:21
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892330
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Petro123
я бы сказал, если заказчик не просит-платит за "конструктор".
ЗЫ.
посмотри рядом топик "Понятие Рабочее место" - не всё однозначно.

Подобный конструктор будет обладать лишь элементарными функционалом, сложные, большие и масштабируемые системы на нем не строить.
Oracle Designer тоже, типа, конструктор - хотите повторить?
...
Рейтинг: 0 / 0
01.08.2006, 15:35
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33892552
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Estets
Участник
Гость1111 Petro123
я бы сказал, если заказчик не просит-платит за "конструктор".
ЗЫ.
посмотри рядом топик "Понятие Рабочее место" - не всё однозначно.

Подобный конструктор будет обладать лишь элементарными функционалом, сложные, большие и масштабируемые системы на нем не строить.
Oracle Designer тоже, типа, конструктор - хотите повторить?

Лучше приведите названия "большие и масштабируемые системы" построенные не на конструкторах или не используешие элементы конструкторов, если не брать конечно весьма специфичных систем как например ОС.
...
Рейтинг: 0 / 0
01.08.2006, 16:31
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33893041
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
Petro123в вашем случае - клиент меняет структуру БД и создаёт таблицы в моём - добавляет записи! Т.е. то на что и должен работать сервер. Это несоизмеримо!
Потом у меня просто количество атрибутов у объектов может быть 200-300. Если создавать 200-300 таблиц на клиенте пользователем это изврат.
200-300 таблиц - это плохо. Но какая сущность содержит 200-300 СПРАВОЧНЫХ атрибутов? Это либо очень спецефическая задача с автоматизированным вводом, либо ненормализованная сущность. Либо денормализованная намеренно таблица для достижения спецефических результатов. Какой менеджер будет использовать столько атрибутов товара, заказчика и проч.?
Насчет несоизмеримо - если справочники однотипные - да, а если нет? Управление полями в этой таблице выльется в крупную головную боль.
Гость1111Структура БД, состав документов, форм, и приложения должна быть определена на этапе проектирования.
Нет, поскольку система продажная, и состав заказчиков неизвестен до момента продаж, известен только класс решаемых задач. Например 1С не знают в момент проектирования, какие формы выпустит соотв. орган.
Petro123я бы сказал, если заказчик не просит-платит за "конструктор". Это как организовать продажу продукта. В любом случае реализация (1 или много таблиц) от заказчика будет скрыта и на интерфейсе не скажется. Критерий один - внутреннее удобство реализации и поддержки.
...
Рейтинг: 0 / 0
01.08.2006, 19:14
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33893744
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Лео
200-300 таблиц - это плохо. Но какая сущность содержит 200-300 СПРАВОЧНЫХ атрибутов?
======== поиск по EAV и увидишь кучю примеров.

Это либо очень спецефическая задача с автоматизированным вводом, либо ненормализованная сущность. Либо денормализованная намеренно таблица для достижения спецефических результатов. Какой менеджер будет использовать столько атрибутов товара, заказчика и проч.?
=========== IMHO вы мало работали.

Насчет несоизмеримо - если справочники однотипные - да, а если нет?
========= бессмыслено говорить без конкретной задачи.

Управление полями в этой таблице выльется в крупную головную боль.
======= в какой?

ЗЫ.
Например, учёт зданий-недвижимости градоначальника.
Сначала атрибуты - адрес, застройщик, площадь, ..........
После запуска в эксплуатацию потребовалось учитывать новый/ые атрибуты - ДавалЛиВзятку (BOOLEAN)
===========
Что будешь делать - проектировщик?
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
02.08.2006, 10:34
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33893760
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
авторНапример 1С не знают в момент проектирования, какие формы выпустит соотв. орган.
т.е. вы хотите сказать, что 1С меняет структуру БД при изменении форм?

ЗЫ. Мы смешали в кучу всё подряд. Тема топика - справочники а не конструктор справочников.
Я бы не хотел рассматривать программы - конструкторы типа 1С с его КОНФИГУРАТОРОМ.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
02.08.2006, 10:38
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33893858
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Estets
Участник
Лео Petro123в вашем случае - клиент меняет структуру БД и создаёт таблицы в моём - добавляет записи! Т.е. то на что и должен работать сервер. Это несоизмеримо!
Потом у меня просто количество атрибутов у объектов может быть 200-300. Если создавать 200-300 таблиц на клиенте пользователем это изврат.
200-300 таблиц - это плохо. Но какая сущность содержит 200-300 СПРАВОЧНЫХ атрибутов? Это либо очень спецефическая задача с автоматизированным вводом, либо ненормализованная сущность. Либо денормализованная намеренно таблица для достижения спецефических результатов. Какой менеджер будет использовать столько атрибутов товара, заказчика и проч.?
Насчет несоизмеримо - если справочники однотипные - да, а если нет? Управление полями в этой таблице выльется в крупную головную боль.
Истина где-то рядом (с) Ф.Малдер ;)
Я уже упоминал в подобном топике свой подход, все однотипные спрвочники состоящие только из полей код-название (1-покупка/2-продажа, 1-активный счет/2-пассивный...) я свалил в одну таблицу
Код: plaintext
1.
2.
*TYPE int -- типов оказалось больше 150-ти
*CODE int
NANE varchar
А если есть хотя бы еще одно поле, то новая таблица - справочник, таких примерно тоже 150
...
Рейтинг: 0 / 0
02.08.2006, 11:06
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33895827
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Мое ИМХО: работал с системой, в которой ВСЕ справочники слиты в одну таблицу - гемороя не оберешься. В прикладной части были специальные функции работы с каждым типом из справочника.
Что надо: Нужно выделить отдельные сущности - перечисления, однотипные значения можно(да и намного удобней) вынести в отдельную сущность, разноплановые справочники с изменяемыми аттрибутами лучше хранить в отдельных таблицах. Но даже в этом: в чем сложность к редактору справочника привязать DDL-генератор? Примеры те же: MS SQL Enterprise Manager, 1C.
---
aka VIR. No pity. No mercy. No remorse. No Regret
...
Рейтинг: 0 / 0
02.08.2006, 21:09
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33896140
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Estets Гость1111 Petro123
я бы сказал, если заказчик не просит-платит за "конструктор".
ЗЫ.
посмотри рядом топик "Понятие Рабочее место" - не всё однозначно.

Подобный конструктор будет обладать лишь элементарными функционалом, сложные, большие и масштабируемые системы на нем не строить.
Oracle Designer тоже, типа, конструктор - хотите повторить?

Лучше приведите названия "большие и масштабируемые системы" построенные не на конструкторах или не используешие элементы конструкторов, если не брать конечно весьма специфичных систем как например ОС.

Пример промышленного конструктора уже привел - Orcale Designer, пример системы - закупленный тиражируемый биллинг, по которому разработчик должен обеспечить работу и поддержку системы покупателю "от и до"...
...
Рейтинг: 0 / 0
03.08.2006, 08:23
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33896786
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Infernal V. Raven
Мое ИМХО: работал с системой, в которой ВСЕ справочники слиты в одну таблицу - гемороя не оберешься.
В прикладной части были специальные функции работы с каждым типом из справочника.

это всё обоснование?
авторВ прикладной части были специальные функции работы с каждым типом из справочника.
- создать представление view и клиент даже не узнает что у него одна таблица
- если сделать как вы хотите, то вместо вашего геморроя получим новый - операторы DDL по модификации структуры БД.
...
Рейтинг: 0 / 0
03.08.2006, 12:11
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33896810
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
Petro123Например, учёт зданий-недвижимости градоначальника.
Сначала атрибуты - адрес, застройщик, площадь, ..........
После запуска в эксплуатацию потребовалось учитывать новый/ые атрибуты - ДавалЛиВзятку (BOOLEAN)
===========
Что будешь делать - проектировщик?
Внесу в метаинформацию запись об этом поле и запущу генератор.
В случае с одной таблицей - все равно вносить метаинформацию, генератор только не нужен. Акцентирую внимание на различиях - в одном случае нужен генератор, в другом невозможна типизированная ссылочная целостность через FK.
...
Рейтинг: 0 / 0
03.08.2006, 12:19
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33896857
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Petro123 Infernal V. Raven
Мое ИМХО: работал с системой, в которой ВСЕ справочники слиты в одну таблицу - гемороя не оберешься.
В прикладной части были специальные функции работы с каждым типом из справочника.

это всё обоснование?
Нет, полученный опыт.
Petro123 авторВ прикладной части были специальные функции работы с каждым типом из справочника.
- создать представление view и клиент даже не узнает что у него одна таблица
- если сделать как вы хотите, то вместо вашего геморроя получим новый - операторы DDL по модификации структуры БД.
Опять же view вы собираетесь делать ручками? Если да - то и таблицы справочников править можно напрямую. А DDL-генератор вещь довольно тривиальная.
...
Рейтинг: 0 / 0
03.08.2006, 12:32
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33896939
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Лео
давай с небе на землю и ближе к практике
Лео
Внесу в метаинформацию
========== это в терминологии администратора БД и схемы БД где?

запись об этом поле и запущу генератор.
========== это что и приведи код (ХП\COM\ExtProc\DLL\.....)

В случае с одной таблицей - все равно вносить метаинформацию
=== какую?

, генератор только не нужен. Акцентирую внимание на различиях - в одном случае нужен генератор, в другом невозможна типизированная ссылочная целостность через FK.
========== вот это уже ближе к конкретики, ещё забыл, что DLL и генераторы это безопасность

авторВ случае с одной таблицей - все равно вносить метаинформацию
INSERT INTO СписокАтрибутов VALUES ('333', 'Давал взятку', 'id_BOOLEAN')
для сервера это не мета...., а обыкновенная запись.


"Сложнее всего в мире достигнуть простоты - это крайняя граница опыта и последнее усилие гения".
George Sand.
...
Рейтинг: 0 / 0
03.08.2006, 12:53
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33896985
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
Внесу в метаинформацию
========== это в терминологии администратора БД и схемы БД где?
Не очень понял вопрос.

запись об этом поле и запущу генератор.
========== это что и приведи код (ХП\COM\ExtProc\DLL\.....)
Пока генераторы команд DDL были оформлены процедурами, будут наверное классами. Так удобнее. Сами команды легко структурируются.

В случае с одной таблицей - все равно вносить метаинформацию
=== какую?Сами написали:
Код: plaintext
INSERT INTO СписокАтрибутов VALUES ('333', 'Давал взятку', 'id_BOOLEAN')

Она во всех случаях одинакова.

, генератор только не нужен. Акцентирую внимание на различиях - в одном случае нужен генератор, в другом невозможна типизированная ссылочная целостность через FK.
========== вот это уже ближе к конкретики, ещё забыл, что DLL и генераторы это безопасность
Можно пояснить?
...
Рейтинг: 0 / 0
03.08.2006, 13:05
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33897028
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
Infernal V. RavenMS SQL Enterprise Manager При чем тут EM ? EM - это бизнес приложение (мы вроде о них) ? Infernal V. Raven1CПочему то часто вспоминают по 1С.
1С - успешный, хороший продукт, но это не значит что тамошние решения являются эталоном. Не надо выдавать нужду за добродетель.
Это
Infernal V. Ravenв чем сложность к редактору справочника привязать DDL-генератор? - другая крайность. Давать пользователям права на DDL зело не рекомендуется. Более того, админам тоже (другое дело, что у них эти права трудно отобрать). Изменять структуру БД - удел разработчиков.

IMO надо разделять справочники и справочники. Неизменный набор атрибутов, к-е описываются стандартными таблицами. И переменный (обычно они называются дополнительными атрибутами), к-й можно реализовать и в "единой" таблице. Доп атрибуты - суть есть дополнительная информация, структурированная для удобства, которую можно было бы ввести и в мемо поле. Соответственно в этом случае ссылочной целостностью, неинформативностью схемы, тормозами при выборке и прочими неудобствами единой таблицы можно принебречь.
...
Рейтинг: 0 / 0
03.08.2006, 13:17
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33897060
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
Лео========== вот это уже ближе к конкретики, ещё забыл, что DLL и генераторы это безопасность
Можно пояснить? У пользователя есть потенциальная возможность навернуть как минимум часть данных в таблицах (совсем не те, что "задумывались" разработчиками), а скорее всего и саму таблицу(ы).

Но и это еще не все. Главное(практическое) зло неконтролируемого изменения структуры БД - трудность последующего обновления и сопровождения такой системы.
...
Рейтинг: 0 / 0
03.08.2006, 13:25
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33897106
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
Alexey Kudinov У пользователя есть потенциальная возможность навернуть как минимум часть данных в таблицах (совсем не те, что "задумывались" разработчиками), а скорее всего и саму таблицу(ы).
Но и это еще не все. Главное(практическое) зло неконтролируемого изменения структуры БД - трудность последующего обновления и сопровождения такой системы.
С навернуть данные не соглашусь, команды выдает оттестированный генератор, максимальное зло при ошибке - отказ выполнить действие. Хтя потенциальная возможность действительно есть. Так - же как навернуть свои данные разом дав команду delete. В этом случае один из рубежей обороны отсутствует. Только я в своей практике еще с этим не встречался. А вот с сопровождением соглашусь. Все сопровождение придется делать через эти - же генераторы. Ихмо - целостность это перевешивает.
...
Рейтинг: 0 / 0
03.08.2006, 13:37
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33897241
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
Леонавернуть свои данные разом дав команду delete триггеры рулят :)
ЛеоС навернуть данные не соглашусь, команды выдает оттестированный генератор, максимальное зло при ошибке - отказ выполнить действие. Хтя потенциальная возможность действительно есть. Понимаете, проблемы безопасности - они всегда потенциальные. Действительно, в жизни вряд ли кто будет конструировать специальную строку, чтобы сделать sql-injection например (хотя даже на sql.ru прецеденты были). Тем не менее проблема есть и есть специальные люди - IT аудиторы, к-е вам о ней обязательно напомнят.

Но вот как то раз нам позвонил пользователь. Обычный парень из бек офиса. И задал наивный вопрос - он сам сделал програмку в экселе, она к базе уже коннектится, но что-то список таблиц получить не может, а ему очень надо. Можете помочь ?

Я не делаю из безопасности фетиш, так же как и из ссылочной целостности. Whatever works, как говорится. Но по крайней мере представлять себе возможные последствия своих решений и знать что такое хорошо, а что такое плохо - надо.

ЗЫ - это не вдаваясь в дискуссию о трудоемкости написания генератора и "обновлялки", к-я его использует. Я делал и то и то, обьем работы представляю.
...
Рейтинг: 0 / 0
03.08.2006, 14:06
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33897371
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Alexey KudinovПри чем тут EM ? EM - это бизнес приложение (мы вроде о них) ?Я привел EM как раз как пример DDL-генератора, про клиента я вообще не говорил. Alexey KudinovПочему то часто вспоминают по 1С.
1С - успешный, хороший продукт, но это не значит что тамошние решения являются эталоном. Не надо выдавать нужду за добродетель. Опять пальцем в небо. Читайте выше Alexey KudinovДавать пользователям права на DDL зело не рекомендуется. Более того, админам тоже (другое дело, что у них эти права трудно отобрать). Изменять структуру БД - удел разработчиков.
...Бог мой, сколько написано. Покажите где я говорил, что нужно давать права пользователям на изменение структуры данных? Все остальное ваше ИМХО совпадает с моим, только вы это другими словами говорите.
...
Рейтинг: 0 / 0
03.08.2006, 14:36
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33897443
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
авторЯ привел EM как раз как пример DDL-генератора, про клиента я вообще не говорил EM - это тоже клиент. И 1С. Но задачи 1С и EM совсем разные, п.э. я и удивился что они оба приведены в качестве примеров.
Ладно, проехали, я понял что вы имели ввиду.
Infernal V. RavenПокажите где я говорил, что нужно давать права пользователям на изменение структуры данных? Вы написали "в чем сложность к редактору справочника привязать DDL-генератор"
Я ответил, что сложность в том, что при этом придется дать пользователям права на DDL.

Если вы имели ввиду, что генератор привязать, но пользоваться им будет только программист - то приношу свои извенения, не так понял.
...
Рейтинг: 0 / 0
03.08.2006, 14:49
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33897654
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
Alexey KudinovЕсли вы имели ввиду, что генератор привязать, но пользоваться им будет только программист - то приношу свои извенения, не так понял.
А я имел ввиду, что пользоваться будет пользователь.
...
Рейтинг: 0 / 0
03.08.2006, 15:34
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33898295
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Лео Alexey KudinovЕсли вы имели ввиду, что генератор привязать, но пользоваться им будет только программист - то приношу свои извенения, не так понял.
А я имел ввиду, что пользоваться будет пользователь.Я думаю, что это решение в большинстве случаев все-таки принимать не стоит.
...
Рейтинг: 0 / 0
03.08.2006, 18:18
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33898302
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Alexey KudinovЕсли вы имели ввиду, что генератор привязать, но пользоваться им будет только программист - то приношу свои извенения, не так понял.Теперь вы меня поняли. Наши позиции совпадают.

Все-таки мне кажется, что конфигурацию должен производить человек специально для этого подготовленный и ответственный за работоспособность системы. Тема избитая уже.
...
Рейтинг: 0 / 0
03.08.2006, 18:21
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33898357
Лео
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лео
Участник
Точно, избитая. Конфигуратором пользуется специальная роль. Одна на систему. Просто создавать справочники по заказам 100 клиентов - тоскливо. Проще дать инструмент, и написать, что пользование этим инструментом можно доверить человеку, расбирающемуся в тонкостях системы (при этом не обязательно ему знать SQL). Простого оператора, или даже непростого в эту роль включать не стоит. Но делаться это будет на том конце, без участия основных разработчиков системы. Кстати владелец этой роли и админ могут быть разные люди. Вроде сформулировал.
...
Рейтинг: 0 / 0
03.08.2006, 18:43
| Ответить | Цитировать | Написать  
Производительность при использовании единой таблицы для справочников
    #33908197
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Гость1111Я скорее не про проблему справочников, а про то чем вы моделировать это дело будете, как документировать, как управлять изменениями?
Будете писать свой редактор моделей, метамоделей, cvs и т.п.? - удачи ;)А куда деваться? Кейсы понятия не имеют о словарях, придуманных для управления обобщенными таблицами. Так что как минимум отчеты для документирования писать придется. А лучше и контроль непротиворечивости и полноты словаря против реальных данных.
...
Рейтинг: 0 / 0
09.08.2006, 14:51
| Ответить | Цитировать | Написать  
106 сообщений из 106, показаны все 5 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Производительность при использовании единой таблицы для справочников
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1545109]:
 0ms
get settings:
 8ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 180ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 96ms
get tp. blocked users:
 1ms
others: 223ms
total:  539ms
созд. / загр.: 539ms
x
x
Закрыть


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