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

К сожалению, свой вопрос первоначально задал в не подходящем форуме: http://sql.ru/forum/actualthread.aspx?tid=397676

Хотел бы услышать рекомендации.

Спасибо
...
Рейтинг: 0 / 0
16.02.2007, 17:31
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34337557
гм...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
гм...
Гость
Справочники? в одну, деревянную:
(id, parentid, name, orderOf)
...
Рейтинг: 0 / 0
16.02.2007, 18:29
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34337573
Tyo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tyo
Участник
TykeДоброго всем дня!
Хотел бы услышать рекомендации.
Спасибо

Голосую за вариант с одной таблицей (ну и вторая -- типа справочник справочников).
В противном случае получаете разбухающую структуру БД, постепенно забываете что в каком справочнике хранится и т.п. Причем все эти десятки справочников наверняка надо вести каким-то прикладом, придумывать механизм унификации этого процесса и т.п.
...
Рейтинг: 0 / 0
16.02.2007, 18:39
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34337624
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
вопрос на засыпку:
целосность блюсти бум?
...
Рейтинг: 0 / 0
16.02.2007, 19:03
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34337797
SergGol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergGol
Участник
4321вопрос на засыпку:
целосность блюсти бум?

Справочник справочников
SprId
SprName

Справочник элементов
SprId
ItemId
ItemName

Дочки
…
SprId
ItemId
…..
...
Рейтинг: 0 / 0
16.02.2007, 20:41
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34337801
SergGol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergGol
Участник
Хотя вариант "много справочников" может иметь преимущество с точки зрения блокировок
...
Рейтинг: 0 / 0
16.02.2007, 20:44
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34337978
Tyke
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tyke
Участник
4321вопрос на засыпку:
целосность блюсти бум?
В общем конечно хотелось бы.
...
Рейтинг: 0 / 0
16.02.2007, 23:52
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34337979
Tyke
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tyke
Участник
Tyo
Голосую за вариант с одной таблицей (ну и вторая -- типа справочник справочников).
Вот и я остановился на таком варианте.
...
Рейтинг: 0 / 0
16.02.2007, 23:54
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34338020
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Urri
Участник
Не ограничивайте себя каким-то одним подходом.
В одной большой системе вполне найдется место и объединенным справочникам, когда это уместно, и разложенным по отдельным таблицам.
Думать, объединять ли новый справочник с конгломератом, надо каждый раз заново.
...
Рейтинг: 0 / 0
17.02.2007, 01:00
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34338093
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Tyke 4321вопрос на засыпку:
целосность блюсти бум?
В общем конечно хотелось бы.

Если хочется блюсти целостность, то надо каждый справочник в отдельную таблицу. Иначе в поле со ссылкой на этот справочник можно будет запихать значение ключа из любого другого.
...
Рейтинг: 0 / 0
17.02.2007, 09:53
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34338324
Tyke
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tyke
Участник
Bogdanov Andrey
Если хочется блюсти целостность, то надо каждый справочник в отдельную таблицу. Иначе в поле со ссылкой на этот справочник можно будет запихать значение ключа из любого другого.
Вот! Поэтому я и подумал, что следующий вариант удовлетворяет всем требованиям (могу ошибаться):
Таблица справочник Recource, со следующими полями: id, idResourceDescriptor, name;
Таблица справочник ResourceDescriptor, co следующими полями: id, name;

Дальше идут view, например: viewTimeTable [select * from Resource where idResourceDescriptor = 1], где 1 - соответсвует TimeTable из ResourceDecriptor

Тогда другие таблицы ссылаются на viewTimeTable.id, т.е. и целосность соблюдена и справочник один.
...
Рейтинг: 0 / 0
17.02.2007, 14:37
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34338534
SQL*Plus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL*Plus
Участник
Tyke Bogdanov Andrey
Если хочется блюсти целостность, то надо каждый справочник в отдельную таблицу. Иначе в поле со ссылкой на этот справочник можно будет запихать значение ключа из любого другого.
Вот! Поэтому я и подумал, что следующий вариант удовлетворяет всем требованиям (могу ошибаться):
Таблица справочник Recource, со следующими полями: id, idResourceDescriptor, name;
Таблица справочник ResourceDescriptor, co следующими полями: id, name;

Дальше идут view, например: viewTimeTable [select * from Resource where idResourceDescriptor = 1], где 1 - соответсвует TimeTable из ResourceDecriptor

Тогда другие таблицы ссылаются на viewTimeTable .id, т.е. и целосность соблюдена и справочник один.Oracle позволяет создавать FOREIGN KEY только на таблицы, не на VIEW.
Как с этим обстоит дело в других СУБД я не знаю.
...
Рейтинг: 0 / 0
17.02.2007, 17:50
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34339061
Tyke
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tyke
Участник
SQL*PlusOracle позволяет создавать FOREIGN KEY только на таблицы, не на VIEW.
Как с этим обстоит дело в других СУБД я не знаю.
Именно поэтому и спрашивал сначала в разделе Postgres, отуда сюда отправили :) . Хотя скорее всего postgres тоже не даст создать.
...
Рейтинг: 0 / 0
18.02.2007, 13:45
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34340209
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
TykeХотя скорее всего postgres тоже не даст создать.
Сомневаюсь, что хоть одна БД даст создать. Внешний ключ на вьюху - вещь довольно странная логически и непросто реализуемая физически.

Что с моей личной точки зрения не помешало бы РСУБД, так это фича примерно следующего вида:

Код: plaintext
1.
2.
create table dictionary ( dictionary_id integer, record_type varchar( 10 ), ... ) ;

alter table data add foreign key ( dictionary_id, 'RECTYPE#1' ) references dictionary ( dictionary_id, record_type ) ;
...
Рейтинг: 0 / 0
19.02.2007, 10:53
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34340355
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
TykeИменно поэтому и спрашивал сначала в разделе Postgres, отуда сюда отправили :) . Хотя скорее всего postgres тоже не даст создать.Именно для Postgres вы можете воспользоваться наследованием, когда все записи наследуемых таблиц просматриваются как записи предка, при этом ключи определяются непосредственно к наследникам.
Но насколько это удобно - судить Вам.
...
Рейтинг: 0 / 0
19.02.2007, 11:33
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34340598
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
В общем то по этому поводу много копий сломано,отчасти из за этой статьи,но мы например,используем все равно много таблицы на каждый справочник (целостность,скорость поиска в запросах и все такое).интерфейс одинаков для всех.в форму справочника подается имя таблицы и названия столбцов на русском и английском (потом может сделаем автополучение из словаря системы).далее все делается само.
...
Рейтинг: 0 / 0
19.02.2007, 12:41
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34340654
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
softwarerЧто с моей личной точки зрения не помешало бы РСУБД, так это фича примерно следующего вида:

Код: plaintext
1.
2.
create table dictionary ( dictionary_id integer, record_type varchar( 10 ), ... ) ;

alter table data add foreign key ( dictionary_id, 'RECTYPE#1' ) references dictionary ( dictionary_id, record_type ) ;

+1
даже
Код: plaintext
alter table data add foreign key ( F1(dictionary_id, ...), F2(...), ... ) references dictionary ( ...) )
где F1(), F2()- детерменированные функции, не выглядит слишком уж страшным в реализации.

А пока целостность можно обеспечить храня в данных (data.dict_record_type ) то, чему место в словаре.
...
Рейтинг: 0 / 0
19.02.2007, 12:55
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34340934
Michael Vasilev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Michael Vasilev
Участник
Мы выбрали вариант для каждого справочника отдельную таблицу.
На на мой взгляд это проще и гибче. Так же как и при слиянии в одну таблицу,
в разных таблицах можно описать, что содержиться в конкретном справочнике,
соответственно не забудется. Кол-во таблиц вырастает, но на понятность
схемы БД, на мой же взгляд, это не влияет. Таблицы справочники всегда со схемы можно
убрать. При применении одной таблицы для этих нужно, схема становится запутанней.
Опять же это мое мнение. Кроме того, если сливать справочники в одну таблицу, тогда, могут появиться несколько разных видов справочников.
Соответственно, одинаковые справочники хранятся в одной таблице, если структура справочника отличатеся от структуры этой таблицы, в других таблицах.
Т.е. в системе начинают применяться разнородные правила, что, на мой взгляд, усложняет дальнейшу поддержку-развитие.
Если в дальнейшем к справочнику понадобиться добавить поле (изменить тип поля), придется
выносить справочник за пределы одной таблицы, с перемастыриванием связей, структуры БД и
приложений.
...
Рейтинг: 0 / 0
19.02.2007, 14:03
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34341206
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Bogdanov AndreyЕсли хочется блюсти целостность, то надо каждый справочник в отдельную таблицу. Иначе в поле со ссылкой на этот справочник можно будет запихать значение ключа из любого другого.Совсем необязательно. Пример
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
CREATE TABLE DictionaryType (
	id tinyint PRIMARY KEY
	, Name varchar( 255 )
)
CREATE TABLE Dictionary (
	TypeID tinyint REFERENCES DictionaryType(ID)
	, ID int PRIMARY KEY
	, Name varchar( 255 )
	, UNIQUE (TypeID, ID)
)
CREATE TABLE Data (
	ID int PRIMARY KEY
	, DictTypeID tinyint CHECK (DictTypeID IN ( 1 ,  3 ,  10 ))
	, DictID int
	, Data varchar( 255 )
	, FOREIGN KEY (DictTypeID, DictID) REFERENCES Dictionary(TypeID, ID)
)
GO
INSERT INTO DictionaryType (id, Name) VALUES ( 1 , 'First')
INSERT INTO DictionaryType (id, Name) VALUES ( 2 , 'Second')
INSERT INTO Dictionary (TypeID, id, Name) VALUES ( 1 ,  1 , '1')
INSERT INTO Dictionary (TypeID, id, Name) VALUES ( 2 ,  2 , '2')
INSERT INTO Data (ID , DictTypeID, DictID, Data) VALUES ( 1 ,  1 ,  1 , 'One')
INSERT INTO Data (ID , DictTypeID, DictID, Data) VALUES ( 2 ,  3 ,  2 , 'Two')
SELECT * FROM Data
GO
DROP TABLE Data, Dictionary, DictionaryType
...
Рейтинг: 0 / 0
19.02.2007, 15:10
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34341327
Michael Vasilev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Michael Vasilev
Участник
[quot ChA]
DictTypeID tinyint CHECK (DictTypeID IN (1, 3, 10))
[quot]

Получается, что тут в чек логика закладывается, которую потом бывает весьма трудно понять,
особенно если это не документировано и разработчик ушел на другую работу. Впрочем если документированно, то тоже. Система получается с весьма жестскими параметрами.
Если понадобиться DictTypeID = 4 или 8 например, нужно будет лазить в свойства поля таблицы.
...
Рейтинг: 0 / 0
19.02.2007, 15:32
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34341561
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Michael Vasilev ChA
DictTypeID tinyint CHECK (DictTypeID IN (1, 3, 10))
Получается, что тут в чек логика закладывается, которую потом бывает весьма трудно понять, особенно если это не документировано и разработчик ушел на другую работу. Впрочем если документированно, то тоже. Система получается с весьма жестскими параметрами.Речь шла только о принципиальной возможности обеспечить целостность стандартными механизмами СУБД, без использования процедурного кода. Такая схема несколько сложнее, чем традиционный подход, но вполне имеет право на жизнь.
Michael VasilevЕсли понадобиться DictTypeID = 4 или 8 например, нужно будет лазить в свойства поля таблицы.А при стандартном подходе придется мудрить, как сделать возможными ссылки из одного поля на разные таблицы. Не уверен, что это будет проще сделать.
...
Рейтинг: 0 / 0
19.02.2007, 16:20
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34341609
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
ChAСовсем необязательно.
Ну назвать предложенное - решением у меня язык не поворачивается. Вместо одной колонки на каждую ссылку заводить две? И это в таблицах с данными? Бананами можно гвозди забивать, но никто этого не делает. :)

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

Честно скажу, не понимаю что значит ссылки из одного поля на разные таблицы. Для чего это такой зверь понадобился? Есть у нас справочники валют, стран и марок автомобилей и нам одно поле нужно которое ссылается на один из справочников? Это верх извращенности в дизайне.
...
Рейтинг: 0 / 0
19.02.2007, 16:30
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34341787
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Bogdanov AndreyНу назвать предложенное - решением у меня язык не поворачивается. Вместо одной колонки на каждую ссылку заводить две? И это в таблицах с данными?1. Вам "шашечки" или ехать ? Упомянутую Вами проблему эта схема решает ?
2. Да хоть десять, в чем проблема ?
3. А почему нет ? Вы про составные ключи не слышали ? А про миграцию ключей ?

Bogdanov AndreyЧестно скажу, не понимаю что значит ссылки из одного поля на разные таблицы. Для чего это такой зверь понадобился? Есть у нас справочники валют, стран и марок автомобилей и нам одно поле нужно которое ссылается на один из справочников?Рад за Вас, что не приходилось с подобным встречаться. А теперь представьте, что документ может иметь взаимоисключительное отношение либо к сотруднику, либо к отделу, либо к партнеру. Или коды аналитического учета. А с учетом того, что со временем появляются новые сущности ? Если подумать, можно, наверное, еще ситуации вспомнить, но лень. Ваши действия в подобных ситуациях ? Желательно, не очень извращенные... ;)

P.S. Предлагается обсуждать без излишних эмоциональных оценок, типа: "язык не поворачивается", "верх извращенности " и т.п. Желательно, внятные аргументы.
...
Рейтинг: 0 / 0
19.02.2007, 17:05
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34341839
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
ChAЕсли подумать, можно, наверное, еще ситуации вспомнить, но лень.Можно я?
Дать настройщику возможность создавать собственные справочники чего-то там, собственные виды документов про то да се, а также связвывать одно с другим.
...
Рейтинг: 0 / 0
19.02.2007, 17:15
| Ответить | Цитировать | Написать  
Дизайн: много справочников vs один + много view
    #34341961
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
ChA1. Вам "шашечки" или ехать ? Упомянутую Вами проблему эта схема решает ?
2. Да хоть десять, в чем проблема ?
3. А почему нет ? Вы про составные ключи не слышали ? А про миграцию ключей ?


Сначала искуственно создаем проблему, запихивая справочники в одну таблицу. А потом пытаемся ее решать. Я так понял, что ваша реплика была в защиту дизайна при котором все справочники запихиваются в одну таблицу. Честно скажу, что предлагаемое решение мне категорически не нравится. Мне в общем-то достаточно и эстетических соображений. Но могу привести и другие: например, объем таблицы с данными разбухает вдвое. Не особенно удобно предлагаемое решеие и для разработки приложений, так как заставляет где-то иметь списки констант, представляющих тот или иной справочник.

ChA А теперь представьте, что документ может иметь взаимоисключительное отношение либо к сотруднику, либо к отделу, либо к партнеру.

Это означает, что документ имеет отношение к некоторой сущности, которая называется скажем "субъект". А уж сотрудник, отдел или партнер - подтипы данной сущности. Итого мы имеем один справочник под названием "Субъекты" и три дочерних справочника. Но при этом никаких DictType в таблице данных у нас не будет.
...
Рейтинг: 0 / 0
19.02.2007, 17:41
| Ответить | Цитировать | Написать  
25 сообщений из 28, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Дизайн: много справочников vs один + много view
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=34337557&tid=1544724]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 167ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 79ms
get tp. blocked users:
 2ms
others: 229ms
total:  520ms
созд. / загр.: 520ms
x
x
Закрыть


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