powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование атомарных справочников...
25 сообщений из 325, страница 5 из 13
Проектирование атомарных справочников...
    #38530934
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChAкоторые добавляет любой пользователь по своему усмотрениюМаша, которую ввел в обсуждение SERG1257, и "лак для ногтей" - это, конечно, утрирование для красного словца.
Даже такие классификаторы должен, наверное, создавать по необходимости специально обученный человек.. )

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

Продемонстрируйте, пожалуйста, взгляд, при котором пол и национальность - одна сущность. Дико интересно.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38530969
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sgt.PepperВот это место я не очень понял:ChAВернёмся к вашему примеру. Если в модели данных классификатор пола никак не связан с другими сущностями, в частности, с персональными данными, то алгоритм никак не поймёт, что тут надо считать так, а здесь эдак. Я и сказал, что такие справочники, которые как Вы говорите "входят в модель данных", не годятся для формирования на лету.Не хотелось возвращаться, ноги растут вот отсюда 15433255 .
Если мы говорим о целостной и непротиворечивой модели данных(МД) ПО, то ни о какой кнопке "Создание нового справочника" говорить нельзя. В контексте топика это подразумевает создание новой сущности, не связанной ни с какими другими, т.е., по сути, не входящая в МД ПО. Для её включения необходимо связать с другими сущностями, что требует создания в этих сущностях соответствующего атрибута(ов), хранящего ссылку(и) на элемент(ы) нового классификатора. Иногда даже отдельной сущности для реализации связи между новым классификатором и сущностью, его использующей. Но это уже подразумевает не просто создание "справочника", это уже изменение модели данных, что доверять обычному пользователю кажется несколько эксцентричным, на мой взгляд. В противном случае, такой справочник не имеет никакого отношения к МД ПО.
Проблема в том, что глобальный классификатор всего и вся превращает реляционную модель в "кашу", которая требует добавления сложной метамодели и написания промежуточного слоя для интерпретации и обработки данных. Таким образом МД ПО, которая нормально реализуема в терминах реляционной МД, зачем-то поднимается на уровень выше и там управляется неким "универсальным" программным кодом, которые выполняет, по сути, то же самое, что могда бы делать сама РСУБД с помощью своих стандартных встроенных механизмов. В частности, большинством видов проверки корректности данных и управления доступом.
В результате, ничто не мешает ссылочному атрибуту присвоить в качестве значения идентификатор любого из справочников, входящий в "глобальный" классификатор, кроме некоего "универсального" кода, при условии, если все клиенты будут им пользоваться, что не факт, не считая ошибок реализации такового. А уж реализации управления доступом и вовсе становится танцами на льду в роликовых коньках. Причём это вовсе не исключает, что такого категорически не надо делать, просто, на мой взгляд, этим слишком часто злоупотребляют. Всем хочется делать свои конструкторы Вселенной и лень разбираться в ПО.Sgt.PepperChAналичие механизма построения дополнительной семантической сети поверх существующих данных может оказаться полезным, в том числе для дальнейшей эволюции модели, я сам таким занимался. И я не призывал использовать их всегда и везде.
Я не согласен с отрицанием возможности такого функционала в принципе и удивлялся некоторым особенностям его реализации типа патчей на БД и прогу...Отрицается, если правильно понял, не функционал, как таковой, а принадлежность его МД ПО.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38530988
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA В контексте топика это подразумевает создание новой сущности, не связанной ни с какими другими, т.е., по сути, не входящая в МД ПО. Для её включения необходимо связать с другими сущностями, что требует создания в этих сущностях соответствующего атрибута(ов), хранящего ссылку(и) на элемент(ы) нового классификатора. Иногда даже отдельной сущности для реализации связи между новым классификатором и сущностью, его использующей. Но это уже подразумевает не просто создание "справочника", это уже изменение модели данных, что доверять обычному пользователю кажется несколько эксцентричным, на мой взгляд. Откуда такое недоверие?

ChAПроблема в том, что глобальный классификатор всего и вся превращает реляционную модель в "кашу", которая требует добавления сложной метамодели и написания промежуточного слоя для интерпретации и обработки данных.
не данных, а модели

ChA Таким образом МД ПО, которая нормально реализуема в терминах реляционной МД, зачем-то поднимается на уровень выше и там управляется неким "универсальным" программным кодом, которые выполняет, по сути, то же самое, что могда бы делать сама РСУБД с помощью своих стандартных встроенных механизмов.
если бы РСУБД могла бы интерпретировать метамодель и "разложить" по полочкам в своих терминах и генерировать методы доступа, то нужды в допслое не было бы. Встроенные механизмы РСУБД куцые, например есть механизм union, но нет механизма шаблона для union, все везде на уровне экземпляров (это бы избавила ТС от мегаклассификатора)
ChAВ частности, большинством видов проверки корректности данных и управления доступом.
Корректность ссылок (и то не полностью) и кортежа (и то обрубок на уровне одного кортежа - ну, в МССКЛ)
ChAВ результате, ничто не мешает ссылочному атрибуту присвоить в качестве значения идентификатор любого из справочников,
входящий в "глобальный" классификатор, кроме некоего "универсального" кода, при условии, если все клиенты будут им пользоваться, что не факт, не считая ошибок реализации такового.
не любого а нужного если ссылка типизирована и эту типизацию не обойдешь

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

ChAОтрицается, если правильно понял, не функционал, как таковой, а принадлежность его МД ПО.
у ПО нет МД обычно
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531077
AlexJm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> При одном взгляде "Пол" и "Национальность" - это разные сущности, а при другом одна, "справочник"

Продемонстрируйте, пожалуйста, взгляд, при котором пол и национальность - одна сущность. Дико интересно.

guest_20040621Мои ответы для вас будут стоить $800/академический час, минимальный контракт - пятидневная рабочая неделя.

))
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531122
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин 1. Разделение на сущности условно. При одном взгляде "Гендиректор" и "уборщица" это разные сущности, а при другом -одна, "должность в штатном расписании". При одном взгляде "Пол" и "Национальность" - это разные сущности, а при другом одна, "справочник".Вообще непонятно. Поясни что хотел сказать. Можно с примерами
Кот Матроскин 2. Практические преимущества от "сгоняния нескольких сущностей в одну таблицу" для "пола" и "национальности" такие же, как для "гендиректора" и "уборщицы" - удобство единообразной обработки. А вот с этим все понятно. Имеется форма(поиск/редактирование) которая вызывается несколько раз с разными параметрами, красота. Но, та же форма может вызываться (я не в жисть не поверю что вы не умеете это делать) против разных табличек (с одинаковыми именами), ну или на крайняк скопипастите в другую форму. И едиственная причина по которой вы так не делаете, это то, что вы не придавали этому значения, а сейчас спорите только из чувства противоречия.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531130
AlexJm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257А вот с этим все понятно. Имеется форма(поиск/редактирование) которая вызывается несколько раз с разными параметрами, красота. Но, та же форма может вызываться (я не в жисть не поверю что вы не умеете это делать) против разных табличек (с одинаковыми именами), ну или на крайняк скопипастите в другую форму. И едиственная причина по которой вы так не делаете, это то, что вы не придавали этому значения, а сейчас спорите только из чувства противоречия.
Ничего, что я отвечу? Единственная причина, по которой он так делает - то, что он это реально разрабатывает. И то, что кол-во этих атомарных сущностей может исчисляться тысячами. Не подскажете, сколько там в среднем строк получится триггер instead of на представление с union all? Или Вы сторонник динамического sql на клиентской машине?
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531143
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexJm Единственная причина, по которой он так делает - то, что он это реально разрабатывает.А я это реально поддерживаю. И очень хочу чтобы инфа хранилась в словаре БД, а не в голове у разработчика.
AlexJm И то, что кол-во этих атомарных сущностей может исчисляться тысячами. Таки тысячам, ага. И все тысячи имеют одинаковый набор полей и одинаковый набор прав. А может урежем осетра до десятков. Только честно перед самим собой.
AlexJm Не подскажете, сколько там в среднем строк получится триггер instead of на представление с union all?А это еще зачем. Я утверждал что если есть необходимость слить данные, то вьюха это выход. Сливать легко, делить трудно.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531263
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> При одном взгляде "Пол" и "Национальность" - это разные сущности, а при другом одна, "справочник"

Продемонстрируйте, пожалуйста, взгляд, при котором пол и национальность - одна сущность. Дико интересно.

Я же описал его - это примеры сущности "справочник". Бывает справочник полов, бывает - справочник национальностей, но и то и другое- справочник.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531275
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Кот Матроскин 1. Разделение на сущности условно. При одном взгляде "Гендиректор" и "уборщица" это разные сущности, а при другом -одна, "должность в штатном расписании". При одном взгляде "Пол" и "Национальность" - это разные сущности, а при другом одна, "справочник".Вообще непонятно. Поясни что хотел сказать. Можно с примерами
Я специально упомянул примеры в своей фразе - даже не знаю куда тут подробнее. Есть с точки зрения системы сущность "справочник", есть - "элемент справочника". Что тут непонятного?
SERG1257Кот Матроскин 2. Практические преимущества от "сгоняния нескольких сущностей в одну таблицу" для "пола" и "национальности" такие же, как для "гендиректора" и "уборщицы" - удобство единообразной обработки. А вот с этим все понятно. Имеется форма(поиск/редактирование) которая вызывается несколько раз с разными параметрами, красота. Но, та же форма может вызываться (я не в жисть не поверю что вы не умеете это делать) против разных табличек (с одинаковыми именами), ну или на крайняк скопипастите в другую форму. И едиственная причина по которой вы так не делаете, это то, что вы не придавали этому значения, а сейчас спорите только из чувства противоречия.

"разные таблички с одинаковыми именами" - это что-то макабрическое :)
Я имел в виду не формы выбора, а именно ту самую кнопку "создать справочник". В режиме "одна таблица" она не требует
выдачи прав drop/create для обычного пользователя - это хорошо. Не требует использования динамического SQL, что еще лучше.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531306
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин "разные таблички с одинаковыми именами" - это что-то макабрическое :)С одинаковыми именами полей.
Кот Матроскин а именно ту самую кнопку "создать справочник". Зачем в приложении кнопка "создать справочник" если это не EAV. см 15433255 . Нет если у вас EAV, то претензия снимается.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531328
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Я же описал его

Кот Матроскин, вы запускаете очередной виток переливания из пустого в порожнее.

Меня расстраивает то, что все делятся исключительно собственным опытом и работающими примерами. С одной стороны, это понятно: хорошо знакомые приёмы, преимущества и недостатки. С другой - неужели каждый считает своё решение законченным шедевром? Ответьте [себе] на простые вопросы: какие задачи решает датацентическое приложение? В чём заключается роль стандартов? Почему вы можете предъявить формальные требования к технологической операции, но не можете сделать то же самое в отношении структуры данных?
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531371
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Кот Матроскин 1. Разделение на сущности условно. При одном взгляде "Гендиректор" и "уборщица" это разные сущности, а при другом -одна, "должность в штатном расписании". При одном взгляде "Пол" и "Национальность" - это разные сущности, а при другом одна, "справочник".Вообще непонятно. Поясни что хотел сказать. Можно с примерами

Ну, может быть, он хотел сказать, что в одной ПО, "Национальность" - сущность, а в другой атрибут? Например, в БД про народы мира "Национальность" имеет атрибуты типа: "Впервые упоминается", "Основное место проживания" и т.д. А в другой БД про тюрьмы народов мира просто свойство заключенного.
Но просто выразил это в зашифрованном таком виде - "одна сущность" = "разные свойства одной сущности"?
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531424
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Нет если у вас EAV, то претензия снимается.
Об том и речь: конструктор для конечного пользователя - сущности в EAV, их классификация - одна таблица для всех классификаторов.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531472
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинguest_20040621> При одном взгляде "Пол" и "Национальность" - это разные сущности, а при другом одна, "справочник"

Продемонстрируйте, пожалуйста, взгляд, при котором пол и национальность - одна сущность. Дико интересно.

Я же описал его - это примеры сущности "справочник". Бывает справочник полов, бывает - справочник национальностей, но и то и другое- справочник.
вот и прекрасно.

не сущность "справочник" (её нет в предметной области ) а мета-сущность (она, эта сущность, из области не модели ПО, она в словаре описания самой модели)

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

Можем даже создать генератор новых таблиц-справочников (в некоторых случаях (ddl в транзакциях допустим) - даже прямо в СУБД, в некоторых других(ddl внетранзакционен) - из клиентов). Но это если совсем спинку почесать захотелось. (хотя если мы сознательно продвигаем еав, как возможность изменить всё пользователем без участия кодера, - то, как знатный еавист виппрос пишет, - никуда мы от переноса логики в код не уйдём, вынуждены будем предоставлять юзеру возможность сделать из БД помойку по вкусу. прострелить не одну ногу, а обе и голову с руками). там и универсальная таблица не криминал, не то, что справочник.

вот собсна и всё.


я почему тут высказываюсь - работал я в системе с ленивым универсальным "справочником", несколько надоело (основные претензии - именно проблемность поддержки логической целостности и вытекающими из ЛЦ плюшками оптимизации запросов, которыми вы не имеет право пользоваться, пока не уверены в логической целостности). при переносе на другую субд новые (и некоторые старые) справочники вынес в самостийные, добавил метаописатель (ленивый) => получил универсальный интерфейс. Всё.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531508
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Я же описал его

Кот Матроскин, вы запускаете очередной виток переливания из пустого в порожнее.

Меня расстраивает то, что все делятся исключительно собственным опытом и работающими примерами. С одной стороны, это понятно: хорошо знакомые приёмы, преимущества и недостатки. С другой - неужели каждый считает своё решение законченным шедевром? Ответьте [себе] на простые вопросы: какие задачи решает датацентическое приложение? В чём заключается роль стандартов? Почему вы можете предъявить формальные требования к технологической операции, но не можете сделать то же самое в отношении структуры данных?
guest_20040621, ну Вы же мне задали конкретный вопрос, я Вам на него отвечаю - вы называете это переливанием из пустого в порожнее. Зачем задавать тогда было?
Я, кстати, описываю как раз не свою систему, а то, что сейчас сопровождаю. И я сразу же сказал - в общем случае этот подход
скорее плох, чем хорош (потому что для 80% приложений нафиг не нужна кнопка "создать custom справочник"). Но если кнопка-таки необходима - то сливание этих справочников в единую таблицу это самый прямой способ ее сделать.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531517
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> вы называете это переливанием из пустого в порожнее

Приношу извинения, был неправ.

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

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

Заводите, старина - разве ж Вам кто-то запрещает? Вы считаете необходимость выдавать пользователю права на drop/create и использование динамического SQL достоинством? Мне так не кажется.

проблемность поддержки логической целостности
Имхо проблемы логической целостности для справочников Вы несколько преувеличиваете. Вам кажется, что установка КАМАЗу
классификации "легковой автомобиль" (то что не отловит никакая ссылочная целостность) - это все цветочки, а установление
классификации "женский пол" - это ужас-ужас? Почему? Второе гораздо легче отловить, как минимум.
Проблема не в универсальных справочниках, а в том что надо избегать писать в базу всякую чушь, независимо от того, отлавливается ли чушь ОЦ или нет.
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531560
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621,

Вот Вы помянули про формальные требования к модели данных - хорошо, давайте посмотрим с этой стороны.
Вы считаете, что эти формальные требования - никак не зависят от задачи, которую решает схема данных? Можно выделить универсальные ФТ? И единая таблица справочников им категорически противоречит?
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531630
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq(хотя если мы сознательно продвигаем еав, как возможность изменить всё пользователем без участия кодера, - то, как знатный еавист виппрос пишет, - никуда мы от переноса логики в код не уйдём, вынуждены будем предоставлять юзеру возможность сделать из БД помойку по вкусу. прострелить не одну ногу, а обе и голову с руками). там и универсальная таблица не криминал, не то, что справочник.


В ВИПРОС встроен механизм динамической классификации и ЕАВ используется только в виде пула деклассифицированых объектов
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531642
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинqwwqпоэтому заводим (мета)справочник "справочники",

Заводите, старина - разве ж Вам кто-то запрещает? Вы считаете необходимость выдавать пользователю права на drop/create и использование динамического SQL достоинством? Мне так не кажется.
коллега, я считаю само заведение справочника (и любой иной сущности ) пользователем, в т.ч. в еав -- криминалом.


т.ч. это было лир отступление к вопросу о том, как обеспечить криминальный функционал. (иногда таки мы собираемся его обеспечивать, т.к. планируем именно такое, несопровождаемое, бытие кода и бд).


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

*"может" - поскольку "будет ли" -- зависит от реализации (как и в случае самого еав).


Ну и лок на системные таблицы тут не бага, имхо, а фича -- дополнительный ужастик, снижающий активность бездумного заводиста сущностей.
как иначе бить ему по рукам?

но, ещё раз фиксирую - это о гипотетическом случае "почти еава", а не нормально скомпонованной БД.
Кот Матроскинпроблемность поддержки логической целостности
Имхо проблемы логической целостности для справочников Вы несколько преувеличиваете. Вам кажется, что установка КАМАЗу
классификации "легковой автомобиль" (то что не отловит никакая ссылочная целостность) - это все цветочки, а установление
классификации "женский пол" - это ужас-ужас? Почему? Второе гораздо легче отловить, как минимум.
Проблема не в универсальных справочниках, а в том что надо избегать писать в базу всякую чушь, независимо от того, отлавливается ли чушь ОЦ или нет.

мне наплевать на камазы и легковушки. в случае ЛЦ я знаю , что SELECT DISTINCT fk FROM very_big_table; полностью покрывается множеством SELECT id FROM very_small_table; и могу это использовать в запросах к "очень большой таблице".

в отсутствии фк , я могу рискнуть попользоваться этим неявным знанием, но буду бит (возможно - во всех смыслах), если приложение его таки нарушит.
случай со "спутанным фк" с одной - увеличивает "покрывающее множество" (т.е. минимум линейно в разы удорожит такого рода "хаки"), а не дай б-х, приведёт ещё и к необходимости учёта такой возможности в логике (а оно мне надо ?).
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531650
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosqwwq<>


В ВИПРОС встроен механизм динамической классификации и ЕАВ используется только в виде пула деклассифицированых объектов
респект и уважуха
, особенно если на пальцах расшифруете шо це таке "механизм динамической классификации"

т.е. никаких наездов
в т.ч. на вашу любовь к eav
если мы сознательно спускаемся в ад -- надо делать это обстоятельно
насколько я понял -- вы там вполне освоились
элементы же еав есть наверное у всех "в портфолио"
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531667
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqViPRosпропущено...


В ВИПРОС встроен механизм динамической классификации и ЕАВ используется только в виде пула деклассифицированых объектов
респект и уважуха
, особенно если на пальцах расшифруете шо це таке "механизм динамической классификации"

т.е. никаких наездов
в т.ч. на вашу любовь к eav
если мы сознательно спускаемся в ад -- надо делать это обстоятельно
насколько я понял -- вы там вполне освоились
элементы же еав есть наверное у всех "в портфолио"
этот механизм я тут несколько раз расшифровывал
...
Рейтинг: 0 / 0
Проектирование атомарных справочников...
    #38531696
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosqwwqпропущено...

респект и уважуха
, особенно если на пальцах расшифруете шо це таке "механизм динамической классификации"

т.е. никаких наездов
в т.ч. на вашу любовь к eav
если мы сознательно спускаемся в ад -- надо делать это обстоятельно
насколько я понял -- вы там вполне освоились
элементы же еав есть наверное у всех "в портфолио"
этот механизм я тут несколько раз расшифровывал

http://www.sql.ru/forum/actualsearch.aspx?search=???????? ???????????? ?????????????&sin=0&bid=36&a=&ma=0&dt=-1&s=1&so=1

как-то не вижу ничего похожего на "расшифровку". одни декларации.

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


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