Ответ на »сообщение 269« (Geo)

Челябинские программеры настолько суровые, что кодят только в hex-редакторе.

___________________________
Поэтому никак не могу понять проблем. Проблемы в усложнении поддержки. В любой СУБД, названия таблиц, полей, типов и все связи и так присутствуют в системных таблицах, кроме того скрытно для пользователя выполняются некоторые проверки снижающие вероятность ошибки, по сути предлагается сделать то же самое, но самому. Есть так же различные инструменты упрощающие жизнь администратору/архитектору БД, их тоже на помойку. Во имя каких таких высоких целей требуется идти на такие жертвы?

Господа, я, видимо, в выходные слишком торможу. Поэтому никак не могу понять проблем. Попробую на примере.

Пусть у нас есть справочник в таблице LIB. Поля ID и NAME. Есть диспетчерская таблица XATTR с полями ID, NAME (название доплнительного атрибута), ATYPE (тип значения дополнительного атрибута). И есть таблицы для значений каждого типа. Например, XATTR_INT_VAL, XATTR_STR_VAL и т.п. Структура примерно такая: ID, XATTR_ID (ссылка на запись в таблице XATTR), LIB_ID (ссылка на запись справочника, к которой относится данное значение), VAL (собственно значение; тип поля зависит от таблицы).

Естественно, не стоит заводить по одной таблице значений на кадый строковый тип (для VARCHAR(20) своя таблица, для VARCHAR(40) -- своя). Завести просто одну единственную для все строк с максимальной длиной текстовой строки.

Если нужно заводить дополнительные атрибуты для разных справочников, то тут теоретически возможны два варианта: либо привязку к таблице прописываем в XATTR (типа, дополлнитеьный атрибут всегда привязан к конкретной таблице), либо в таблицах XATTR_XXX_VAL (атрибут с одним и тем же названием может быть в разных таблицах, но в XATTR мы его прописываем один раз). В зависимости от БД и решаемых задач может оказаться выгодным как первый, так и второй способ.

Ответ на »сообщение 263« (Сергей Перовский)
___________________________
>>> Все необязательные атрибуты выносятся во вспомогательные таблицы
>>> и присутствуют не в виде колонки, а в виде строки, что не требует NULL-значений.

Вопрос правильно ли определены основные и необязательные.
Если база живая, то будет происходить переоценка.

Ответ на »сообщение 265« (Geo)
___________________________
Будем последовательны.
К каждой (N) вторичной таблице приделаем еще М таблиц атрибутов :)

Ответ на »сообщение 265« (Geo)
___________________________
А в чём достоинства такой схемы? Когда все атрибуты валятся в одну таблицу, это лёгкость введения нового типа атрибутов без внесения изменений в запросы, используемые программой. А тут, если новый тип, то новая таблица, значит, новый запрос, прграмму надо перекомпилировать. К тому же я вижу ещё несколько недостатков такой схемы:

1. Во всех атрибутивных таблицах будет поле "ссылка на атрибут", которое во всех строках будет иметь одинаковое значение. Раздувание объёма базы непонятно зачем.

2. Дублирование информации о типе атрибута: в диспетчерской таблице и в типе поля соответствующей дспетчерской таблицы.

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

Отсюда вопрос: а зачем всё это надо? Хорошо, избавились мы от NULL'ов, но получили кучу других проблем. Стоит ли оно того?

Ответ на »сообщение 264« (Антон Григорьев)
___________________________
>>> Это что - для каждого возможного атрибута отдельная таблица? Вроде как жирно будет. Или там одна таблица, где есть поля "код атрибута" и "значение атрибута"?
Например, вот такой вариант. Есть таблица ("диспетчерская"), в которой определены все дополнительные атрибуты. В частности, наименование и тип. А есть по одной таблице на каждый тип данных из тех, что доступны в той самой диспетчерской таблице. В каждой из них имеется ссылка на определение атрибута в диспетчерской таблице, значение и ссылка на запись, к которой относится данное значение. Таким образом мы получим количество таблиц N+1, где N - кличество доступных типов для дополнительных атрибутов.

Это некая обобщенная принципиальная схема. Детализация зависит от структуры БД.

Ответ на »сообщение 263« (Сергей Перовский)
___________________________

Все необязательные атрибуты выносятся во вспомогательные таблицы и присутствуют не в виде колонки, а в виде строки, что не требует NULL-значений.

А можно с этого места поподробнее? Это что - для каждого возможного атрибута отдельная таблица? Вроде как жирно будет. Или там одна таблица, где есть поля "код атрибута" и "значение атрибута"? Это очень спорное решение, так как атрибуты могут быть разных типов, да и вообще оказаться ссылками на другие объекты, а механизмами СУБД целостность данных в этом случае поддержать невозможно. Придётся сложные триггеры писать.

Просто в проекте, в котором я сейчас участвую, используется БД именно с такой структурой, что доставляет целый ряд неудобств, так что это для меня больная тема.

Ответ на »сообщение 262« (Денис Зайцев)
___________________________
СУБД, которые отказывают пользователям в праве использования NULL-значений
И это правильно (с) М.Горбачев
И, как ни странно, имеет непосредственное отношение к разговору.
Я не использую NULL в сколь-нибудь сложных проектах. По сути, главная таблица используется для связи синтетического ключа с составным естественным ключом, соответственно ключевые поля не могут быть не заполнены. Все необязательные атрибуты выносятся во вспомогательные таблицы и присутствуют не в виде колонки, а в виде строки, что не требует NULL-значений.

Ответ на »сообщение 261« (Сергей Перовский)
___________________________

Что значит "строго реляционными"?

Видимо, имеются в виду Труъ реляционные СУБД, которые отказывают пользователям в праве использования NULL-значений, позволяют SELECT только как SELECT DISTINCT и т.п.

Ответ на »сообщение 257« (Как слышно? Приём!)
___________________________
почему все(!) практические базы данных не удается сделать строго реляционными?
Что значит "строго реляционными"?
Весь SQL построен на манипуляции только таблицами.
Больше никаких сущностей там просто не существует.
Или Вы это про нормализацию?
Так это совсем другой разговор. Хорошо построенные базы нормализованы относительно любого возможного заполнения, а не относительно текущего состояния. Иначе их приходилось бы регулярно переструктурировать.