Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Справочники / 5 сообщений из 5, страница 1 из 1
02.01.2010, 19:57
    #36395880
Hug
Hug
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Справочники
Всем добрый день
Новый проект, а вместе с ними опять новые мысли о формировании справочников.

Вариант1.
Dic1 Dic2 Dic3
По таблице на сущность (города регионы...)

Вариант2
Entities
EntityValues
(в две таблицы. Одна список сущностей, другая значений)

И вроде и плюсы и минусы всего известны.
И вроде везде написано выбирать вариант1, и ORMы уже готовы быстро нагенерировать таблиц,
но все-таки думается об универсальности, хочется без всяких проблем добавлять новые модели.
Хочется думать, что бд получается гибкой и готова проглотить любую новую отрасль, достаточно поменять немного метаданных
С этими мыслями приходят идеи EAV, бд становиться сборищем символов..

Впрочем увлекся. Можно ли делать в относительно больших и долгих проектах вариант2? Есть ли плюсы и мнимая универсальность??

Спасибо за ответы
...
Рейтинг: 0 / 0
03.01.2010, 01:08
    #36396023
egorych
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Справочники
был такой старый холиварчик , почитайте, может пригодится
...
Рейтинг: 0 / 0
03.01.2010, 12:14
    #36396111
Hug
Hug
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Справочники
egorychбыл такой старый холиварчик , почитайте, может пригодится

Ваше мнение?
...
Рейтинг: 0 / 0
03.01.2010, 12:24
    #36396115
egorych
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Справочники
Hug,

вариант 1.
...
Рейтинг: 0 / 0
03.01.2010, 16:28
    #36396214
GrayStrannik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Справочники
HugВпрочем увлекся. Можно ли делать в относительно больших и долгих проектах вариант2? Есть ли плюсы и мнимая универсальность??И что делать, если проект станет-таки востребованным? В первом случае просто разносим таблицы на разные диски. А во втором? Первый вариант логически проще второго - зависимостей меньше и они явные. Соответственно, ошибок меньше плюс их проще искать и исправлять. Если проект станет успешным, то сущности начнут деунифицироваться. У многих из них появятся свойства и связи, характерные только для конкретной сущности. Что при этом делать с остальными? При оптимизации может выяснится, что оптимальные планы запросов для разных сущностей разные. И индексы могут быть нужные разные. Что делать с этим при единой таблице? Некоторые сущности, например, области и республики, лучше держать в памяти (они очень часто запрашиваются), в то время как названия улиц и номера домов - на диске. Что делать с этим, если всё в одной таблице? У сущности изменился тип параметра. В ИНН юриков вдруг появились буквы. В каком случае проще найти список всех необходимых изменений кода? Когда всё в одном или когда всё разложено по своим таблицам?
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Справочники / 5 сообщений из 5, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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