powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Необходимость в использовании множества справочников
25 сообщений из 59, страница 2 из 3
Необходимость в использовании множества справочников
    #38402190
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Идея универсального справочника (как и EAV) просто обязана придти в голову каждому начинающему проектировщику.
Однако взамен ... получаем ...+1
я - противник EAV во всех случаях, когда без него можно обойтись
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38402368
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В_поисках_1Просто хотелось бы выявить приемлемый аргумент (который бы устроил всяких профессоров-д.т.н.'ов), оправдывающий наличие справочников. Я вижу этот аргумент в таком виде - лень/удобство/экономия времени.

Так?
Самое главное - поиск объектов по их свойствам. При поиске значения тоже выбираются из тех же справочников.
Фактически вы классифицируете оьбъекты при помощи классификаторов со всеми вытекающими последствиями.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38402458
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChopSERG1257Идея универсального справочника (как и EAV) просто обязана придти в голову каждому начинающему проектировщику.
Однако взамен ... получаем ...+1
я - противник EAV во всех случаях, когда без него можно обойтисьТогда ответь, для сабжевого случая можно обойтись ?
С учетом, что будет тенденция к росту числа справочников до 30-50.
Если не делать универсального справочника, то неизбежно нужно делать толковый конструктор отдельных справочников + обвязка безопасностью + автоматическая манипуляция этими справочниками в системе. Это немалый участок работы.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38402479
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChopSERG1257Идея универсального справочника (как и EAV) просто обязана придти в голову каждому начинающему проектировщику.
Однако взамен ... получаем ...+1
я - противник EAV во всех случаях, когда без него можно обойтись
ЕАВ-подобные подходы хороши, когда надо организовать презентацию данных. Если каждый справочник вполне "заслуживает" отдельную таблицу, то для их визуализации, напротив, напрашивается одна универсальная форма типа таблицы СуррогатныйАйди - СтроковыйМнемокод - Номер для упорядочивания - Имя/Название - Комментарий/Описание (такова структура большинства простых плоских справочников). Для красивого и правильного отображения справочников в универсальной форме нужно обращаться к стандартным метаданным (словарям) СУБД или хранить собственные метаданные.

Бывают случАи, когда без еав-подобных подходов трудно обойтись и в самой структуре данных. В этом случае тем более нужные какие-то метаданные, которые позволят настроить логику использования этой еавешной беспорядицы и обеспечат ее визуализацию.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38402502
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSV...ответь, для сабжевого случая можно обойтись ?можно
с необходимостью использовать EAV столкнулся только один раз,
да и то грешу на свои кривые руки, что не смог найти кошерного решения для задачи создания N-мерной матрицы :)
LSVС учетом, что будет тенденция к росту числа справочников до 30-50.
Если не делать универсального справочника, то неизбежно нужно делать толковый конструктор отдельных справочников + обвязка безопасностью + автоматическая манипуляция этими справочниками в системе. Это немалый участок работы.и с учетом этого - тоже
структура БД проектируется один раз, потом только дорабатывается
необходимости создавать по 30-50 справочников в месяц...
хоть убей - моего воображения представить такое не хватает,
с-но и толковый конструктор для этого не нужен

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

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

большинство моих справочников имеют стандартную структуру:
1. id
2. pid
3. caption
4. fullcaption
+/- поля, которые необходимы для каждого конкретного случая,

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

как-то, вдохновенный 1С-м , пытался создать класс-шаблон для работы со справочниками,
но как-то так руки не дошли закончить начатое,
остановился на том, что на создание нового справочника с базовым ГУИ/КРУД уходило полчаса,
на тот момент меня это устравивало
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38402949
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
универсальный справочник, EAV и толковый конструктор нужны
разве что при создании тиражного решения всяко-разных интернет-магазинов,
чтобы сайтоклепатель среднего уровня подготовки мог без труда и программирования создать все категории/свойства товара для очередного ларька
и это - немалый участок работы, создать такой универсальный справочник...1. Ну у программиста должны быть "тиражные решения". Иначе он всю жизнь будет боянить в каждой системе одни и те же справочники.
2. При наличии универсального справочника+ EAV, заказчик может сам создать новый справочник и тут же его заюзать.

Любая долгоживущая система (с уклоном в доработки время от времени) должна иметь подобный механизм. Тогда большая часть доработок будет настройками не меняя исх.код. И сама система и ее настройки смогут легко переноситься с одной системы в другую.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403087
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSV1. Ну у программиста должны быть "тиражные решения". не уверен
наработки - должны быть и есть, никуда от этого не денешься,
а тиражные решения - как повезет
LSV2. При наличии универсального справочника+ EAV, заказчик может сам создать новый справочник и тут же его заюзать.это просто продукт на продажу, в котором Заказчик сам себе настраивает справочники как хочет,
без программиста :)
если есть Заказчик на такой продукт, то почему бы и нет?
не уверен, правда, что взялся бы за такой заказ :)
LSVИначе он всю жизнь будет боянить в каждой системе одни и те же справочники.вы - противник повторного использования кода? :)
нет пределов совершенствованию,
никто не мешает создать свой класс/библиотеку функций/базовую структуру БД,
и рефакторить ее хоть до пенсии
LSVЛюбая долгоживущая система (с уклоном в доработки время от времени) должна иметь подобный механизм. Тогда большая часть доработок будет настройками не меняя исх.код. И сама система и ее настройки смогут легко переноситься с одной системы в другую.даже теоретически создание такого механизма,
как и любого другого универсального решения,
посложнее, чем решение нескольких частных случаев,
насколько дороже... не знаю
могу сказать, что
если бы та система, которую мне пришлось сопровождать, была не на EAV,
а обычная реляционная - то сопровождать и дорабатывать ее было бы значительно проще и дешевле,

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

полтора года проработал с системой, а специалистом в ней так и не стал,
с чем столкнулся сам, что накопал и задокументировал - то и знаю
к ЕАВ-у для нормальной работы с ним надо добавить слой метаданных,
который будет отображать реальные соотношения между данными,
либо жесткое документирование, что ничуть не дешевле,
и тогда он становится ничуть не универсальней, чем стандартная реляционная схема,
только гемора больше
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403121
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще то говоря, сабж был не про ЕАВ, а про Единую таблицу для минисправочников.
В средних системах таких справочников нужны сотни. В некоторых постоянно нужны новые (н-р параметры товара).

Для этого вполне подойдет общая таблица. Совсем не значит, что это будет таблица для всех справочников системы.
И ЕАВ предназначен не для всей системы , а для заранее неизвестных параметров.
Т.е. ЕАВ это удобное дополнение к сущ. фиксированной схеме.

Для постоянно эволюционирующей системы, работающей у неск. разных заказчиков, универсальный справочник и ЕАВ - реально нужные вещи.
Любая приличная учетная система имеет нечто подобное, т.к. нужно максимальное отделение бизнес-логики от кода самой программы.

Одноразовые простые проекты могут и обойтись без сабжа. Но это будет хардкод.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403191
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хорошо, давайте по EAV будем копья ломать в других топиках.
LSV В средних системах таких справочников нужны сотниИ кого напрягает лишняя сотня таблиц?

Мне кажется проблема здесь в том что выгоду получают одни, а риски несут другие. И первые вторых никогда не поймут.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403359
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSVВообще то говоря, сабж был не про ЕАВ, а про Единую таблицу для минисправочников.
В средних системах таких справочников нужны сотни. В некоторых постоянно нужны новые (н-р параметры товара).ради интереса глянул ТиС 1С-а семерки...
2 десятка справочников, 3 десятка перечислений (которые можно назвать мини-справочниками)
итого - полсотни штук, в ПУБ-е, если правильно помню, раза в полтора больше
мне кажется вы несколько погорячились по поводу сотен
ТиС для вас мелкая и нетиражная система?
или не работает у нескольких клиентов?
LSVЛюбая приличная учетная система имеет нечто подобное, т.к. нужно максимальное отделение бизнес-логики от кода самой программы.по поводу критериев, по которым определяется приличная система, спрашивать не буду :)
а вот фразу " отделение бизнес-логики от кода самой программы " не понял,
может вы имели в виду не программу, а БД?
иначе мне не понятно, как и главное зачем, отделять бизнес-логику от программы, которая эту бизнес-логику реализует

кстати, вчера забыл спросить,
LSV, а что вы скажете по поводу нормализации, быстродействия БД и других страшных слов ДБА?
если ваша сотня мелких справочников сидит в одной таблице,
то это почти наверняка означает, что с этой таблицей работают если не все, то большинство Пользователей системы,
как они ее поделят?
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403428
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Chop,

("свойства" - "атрибуты" должны жить сами по себе и у пользователя - модельщика должна быть возможность завести скоко надо таких "свойства" - "атрибуты")
"таблички" (классификатор свойств-атрибутов) должны жить сами по себе и у пользователя - модельщика должна быть возможность завести скоко надо таких "табличек"
кроме "табличек" должны быть классификаторы "табличек" (таблички табличек), классификаторы классификаторов,.... и у пользователя - модельщика должна быть возможность завести скоко надо таких классификаторов
и "программный код" (в отличии от "бизнес кода" в понимании ЛСВ) должна автоматически интерпретировать, визуализировать и вести всю эту байду
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403429
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ДБА - тупой баран обычно по части структуризации знаний, технический специалист
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403431
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
СУБД , БД - инфраструктурная фигня, с которыми вынужденно приходиться общаться, как и с дисками и мониторами
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403495
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSV
Вообще то говоря, сабж был не про ЕАВ, а про Единую таблицу для минисправочников.
В средних системах таких справочников нужны сотни. В некоторых постоянно нужны новые (н-р параметры товара).

Для этого вполне подойдет общая таблица. Совсем не значит, что это будет таблица для всех справочников системы.
И ЕАВ предназначен не для всей системы , а для заранее неизвестных параметров.
Т.е. ЕАВ это удобное дополнение к сущ. фиксированной схеме.

Для постоянно эволюционирующей системы, работающей у неск. разных заказчиков, универсальный справочник и ЕАВ - реально нужные вещи.
Любая приличная учетная система имеет нечто подобное, т.к. нужно максимальное отделение бизнес-логики от кода самой программы.

Одноразовые простые проекты могут и обойтись без сабжа. Но это будет хардкод.


Простые с виду вначале справочники, со временем и ростом системы, обычно обрастают дополнительными аттрибутами и требованиями к ним.
И такая помойка станет большой головной болью в перспективе. Не надо зарится на кусок сыра в мышеловке - он только с виду вкусный и легкодоступный, потом когда защимит морду - уже не сможешь от него отделаться!))
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403496
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> должна автоматически интерпретировать, визуализировать и вести всю эту байду

Другими словами, существует явная вспомогательная метамодель. Грандиозный минус - жёсткая привязка к СУБД. Идеологический минус - "размазанность" структуры. Предположим, есть необходимось представить содержимое базы данных в виде процессов. ОК, нет проблем. Теперь мы хотим описывать алгоритмы. ОК, тоже легко, но аргументами будут выступать уже сущности, их экземпляры (и подмножества) и процессы. Либо мы будем вынуждены дублировать описания процессов в новой метамодели (с необходимостью синхронизации и пр. геморроем). Можно по-другому - завести метаметамодель. И вот здесь засада: сложность решения начинает зашкаливать. Ни об одном практическом решении я не слышал.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403505
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621,

метамоделей всего два - структурная и процессная
субд (те, какими пользуемся) - уровень экземплярных моделей, и то куцые в плане реализации
сложность не зашкаливает , а приближается к нормальному
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403515
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> метамоделей всего два - структурная и процессная

Это сейчас две. Нет других задач - нет необходимости в других метамоделях. Понадобится, например, автоматизация поддержки принятия решений - простых вариантов реализации не будет.

> сложность не зашкаливает , а приближается к нормальному

Если бы была возможность всегда использовать только элементы одной модели как аргументы для всех метамоделей, - это было бы универсальным решением. На практике это сложно реализовать, для части аргументов потребуется предварительная интерпретация. Добавьте стандартные задачи - история изменений, локализация, разделение доступа и пр., - я бы не назвал сложность нормальной.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403561
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621,

я дмуаю вот как
струкурная модель дает понимание - как мир может быть обустроен (есть "чек" и есть "президент", имеется потенциальные возможности (связи) становления чеков и президентами)
процессная модель - возможный граф состояний для актуализции потенции
других моделей нет наверное, этих достаточно
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403566
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> я дмуаю вот как

Логично. Только структурных моделей очень много. Посмотрите, как может меняться ваша структурная модель. Может человек стать президентом? Да, если речь идет о лавке. Нет, если речь идёт о государстве: необходимо, чтобы человек был гражданином государства (опустим другие ограничения). Всегда ли президент государства - высшее должностное лицо? Нет, не всегда.

Кроме того, структурные модели имеют свойство существовать параллельно.

> процессная модель - возможный граф состояний

Я добавлю к вашим состояниям ещё два: прогнозируемое значение и пересмотренное значение. Простота моделей сразу куда-то исчезла. ;)

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

привязка ко времени и пространству важно, конечно
структура - всевозможные альтернативы (в динамике)
процесс - возможность актуализации альтернатив
как грила одна дама - "это мое временное мнение", но уже давно :)
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403618
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> структура - всевозможные альтернативы (в динамике)
> процесс - возможность актуализации альтернатив

Вы меня правильно поняли, спасибо.

Ключевой вопрос - отражать ли эту динамику в структуре данных? Если отражать, то как именно? Темпоральность может быть независимой, а может быть связанной, - как обеспечить корректный доступ к истории? Логическое структурирование может быть любым, - как описывать и сопоставлять варианты?

Для этих задач можно найти решения, но imho вы погорячились, назвав сложность обычной. :)
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403664
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621,

динамика должна отражаться в струтуре динамически
классифицировали объект как темпоральный, указали какие свойства темпоральны, задали политики отбора состояний объекта... (последнее по времени, вес набор значений темпоральных свойств , вес набор значений темпоральных свойств в диапазоне,...)
ну вроде и все с темпоральностью?
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403668
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
доступ к истории - политики, описываемые в метаописании объекта
по моему это воще тривиальная задача
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403697
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> динамика должна отражаться в струтуре динамически

Хорошее замечание. В IV квартале были пересмотрены результаты II квартала и на основании этих данных произведены некоторые действия, не описанные в терминах текущей модели. Знакомо, да? Темпоральны и данные, и модель. И никто не обещал идентичности аргументов и явного полного описания моделей. Причём, модель может оказаться темпоральной неожиданно для вас.

> доступ к истории - политики, описываемые в метаописании объекта

События могут быть независимы и могут быть связаны. Изменения могут иметь причиной как событие, так и подмножество событий. Тривиальнейшая задача, чего и говорить.
...
Рейтинг: 0 / 0
Необходимость в использовании множества справочников
    #38403758
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621,

я ж не спорю, что модель должна разиваться
речь иет о том, что хорошо бы иметь инструмент, позволяющий развивать модель не меняя концепцию
...
Рейтинг: 0 / 0
25 сообщений из 59, страница 2 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Необходимость в использовании множества справочников
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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