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

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

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

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

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

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

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

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


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