On 05/01/2010 08:14 AM, Sinix wrote:
> О! а вот и EAV...

И что это такое, EAV?

Здравствуйте, Other Sam, Вы писали:


OS>И что это такое, EAV?
первая строчка в гугле
http://en.wikipedia.org/wiki/Entity-attribute-value_model
(aka модель Тенцера, который конечно автором не является, но who cares?)

Здравствуйте, Sinix, Вы писали:

V>>Существуют. Например, реализация наследования в базе.
S>Я тут покритикую чуть-чуть. Без деталей тяжело судить предметно, но решение кажется надуманным. Единственное общее между всеми лицами в вашем изложении — это то, что все они — люди.
Это не совсем так, но для системы это не важно

S>Правда, непонятно как быть, если появятся юридические. С таблицей IndividualsOrIncorporatedPersons выйдет ровно то же, что и с набором атрибутов — общих полей у них нет. Можно конечно завести в ссылающихся таблицах два внешних ключа с чеком, что один их них null — выглядит так же криво.
Отличная тема: предложить своё усложнение дизайна и тут же его обругать

S>А самая тоска — когда содержимое таблиц зависит от типа лица. Редко, но бывает.
Это как раз способ избежпть такой проблемы.
На концептуальном уровне общие атрибуты есть (например, контакты, участие во всяких списках рассылки...), но на физическом они находятся в других таблицах.

V>>Имея такую структуру, мы можем легко и однотипно обрабатывать все сущности. Например, добавить таблицу "адрес", ссылающуюся на "действующее лицо".
S>Чего-чего? Адреса вообще-то существуют сами по себе.
Зависит от модели. Если вероятность одного адреса у разных лиц практически нулевая и не важна для системы, то адрес вполне может быть атрибутом лица, чтобы не усложнять.

S>Может, вы про табличку "ID лица/ID адреса/тип адреса"? Так её обычно денормализуют или разбивают на несколько.
Нет такой таблицы. Есть таблица адресов со ссылкой на ID того, чей это адрес. Если идентичность адресов станет важна для системы (что практически не вероятно в том случаее), то можно её разбить на две — "адреса" и "связи". Способ ссылки при этом не изменится.

S>Юр. и физлица — вообще идеальный пример влияния дырявых абстрацкий на дизайн.
Дырявые они или нет, но это реальные сущности предметной области, с которыми надо работать.
Впрочем, в примере, который я приводил, различие не в этом. Можно упрощённо считать, что там все лица физические.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, vmpire, Вы писали:

_FR>>>Существуют ли ситуации, когда в реляционной базе данных было бы оправдано (с точки зрения нормального дизайна, а не кривых требований :о)) наличие таблицы только лишь с одним полем: автоинкрементным целым, первичным ключём?
V>>Существуют. Например, реализация наследования в базе.
V>>Пример не выдуманный, отлично жил в работающей системе.

КД>Если он жил именно в таком минимальном варианте — одно поле в базовой таблице объектов, то вам есть еще куда расти
А конструктивные соображения есть или так, высказаться захотелось?

Здравствуйте, vmpire, Вы писали:

V>>>Пример не выдуманный, отлично жил в работающей системе.

КД>>Если он жил именно в таком минимальном варианте — одно поле в базовой таблице объектов, то вам есть еще куда расти
V>А конструктивные соображения есть или так, высказаться захотелось?

По теме топика? Специально посмотрел в стуктуру одной специализированной таблицы ... увы там два поля. Целочисленный первичный ключ+целочисленный идентификатор типа. На первичный ключ есть ссылки из бругих таблиц.

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

---
По теме "реализация наследования в базе" — воспользуйся поиском, я (кажется) приводил здесь описания базовой таблицы объектов, которая эксплуатировалась в нашей базе данных. И что там вокруг неё было навешано — тоже. Лет шесть или семь назад.

---
Таблиц с одним полем, лично я как-то не видел и не вижу в них особого смысла (если не считать таблиц для тестирования). Возможно для создания каких-то подмножеств... Типа есть таблица с кучей записей. А в нашей "одноколоночной" таблице мы храним ID-ы тех, которые удовлетворяют какому-то критерию. Но и то — критериев может много. Не будет же для каждого делать свою таблицу? Значит у нас будет уже таблица с двумя колонками — ID-критерия и ID-объекта.

По мне нормальная таблица — это "сурогатный" (целочисленный) первичный ключ+данные.

Здравствуйте, _FRED_, Вы писали:

_FR>Существуют ли ситуации, когда в реляционной базе данных было бы оправдано (с точки зрения нормального дизайна, а не кривых требований :о)) наличие таблицы только лишь с одним полем: автоинкрементным целым, первичным ключём?

Пришел на ум такой случай: если нужно, чтобы разнотипные объекты (хранящиеся в разных таблицах) использовали одно пространство идентификаторов.

На практике не встречал.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, vmpire, Вы писали:

V>>>>Пример не выдуманный, отлично жил в работающей системе.

КД>>>Если он жил именно в таком минимальном варианте — одно поле в базовой таблице объектов, то вам есть еще куда расти
V>>А конструктивные соображения есть или так, высказаться захотелось?
КД>По теме топика?
...
КД>По теме "реализация наследования в базе"
...
Нет, по теме "есть куда расти". Если по вашему данный дизайн откровенно неграмотен и свойственен необученным школьникам — извольте аргументировать.

Здравствуйте, _FRED_, Вы писали:

_FR>Существуют ли ситуации, когда в реляционной базе данных было бы оправдано (с точки зрения нормального дизайна, а не кривых требований :о)) наличие таблицы только лишь с одним полем: автоинкрементным целым, первичным ключём?

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

Здравствуйте, _FRED_, Вы писали:

_FR>Существуют ли ситуации, когда в реляционной базе данных было бы оправдано (с точки зрения нормального дизайна, а не кривых требований :о)) наличие таблицы только лишь с одним полем: автоинкрементным целым, первичным ключём?

Попробую ещё раз объяснить: никакие фиктивные счётчики мне не нужны: есть отношение Master-Details. Делается оно обычно так: в таблице Details заводится поле MasterId и создаётся foreign key от этого поля на primary key таблицы Master. У меня же такая ситуация, что одни и те же Details в качестве Master могут иметь различные таблицы БД (Master1, Master2). Заводить зоопарк Master1Id, Master2Id и т.п. мне кажется не разуным.

Что я сделал: добавил таблицу DetailsList с одним единственным полем DetailsListId и в таблицу Details добавил колонку DetailsListId, которая ссылается за поле из таблицы DetailsList. Теперь из каждой таблицы, в которой требуется иметь Details я ссылаюсь на DetailsListId, по которому хранится набор необходимых дочерних записей.

Так вот интересует: не изобретаю ли я велосипед, и нет ли для моей ситуации более проверенного решения. А ситуация, говоря кратко, такая — надо получить отношения многие:к-одному между таблицей Details ("многие") и большим количеством других таблиц БД.

Здравствуйте, vmpire, Вы писали:

_FR>>Существуют ли ситуации, когда в реляционной базе данных было бы оправдано (с точки зрения нормального дизайна, а не кривых требований :о)) наличие таблицы только лишь с одним полем: автоинкрементным целым, первичным ключём?
V>Существуют. Например, реализация наследования в базе.
V>Пример: базовый класс: действующее лицо системы (живёт в таблице с одной автоинкрементной колонкой)
V>Дочерние классы: поставщик (таблица "поставщик", ссылается на действующее лицо),потребитель (таблица "потребитель", ссылается на действующее лицо), менеджер (таблица "менеджер ", ссылается на действующее лицо) и так далее.
V>Имея такую структуру, мы можем легко и однотипно обрабатывать все сущности. Например, добавить таблицу "адрес", ссылающуюся на "действующее лицо".
V>Пример не выдуманный, отлично жил в работающей системе.

ИМХО, для описанного сценария больше подойдёт агрегирование, в котором таблица с одной колонкой будет не нужна.

On 05/04/2010 02:00 PM, _FRED_ wrote:
>
> Попробую ещё раз объяснить: никакие фиктивные счётчики мне не нужны:
> есть отношение Master-Details. Делается оно обычно так: в таблице
> Details заводится поле MasterId и создаётся foreign key от этого поля на
> primary key таблицы Master. У меня же такая ситуация, что одни и те же
> Details в качестве Master могут иметь различные таблицы БД (Master1,
> Master2). Заводить зоопарк Master1Id, Master2Id и т.п. мне кажется не
> разуным.
>
> Что я сделал: добавил таблицу DetailsList с одним единственным полем
> DetailsListId и в таблицу Details добавил колонку DetailsListId, которая
> ссылается за поле из таблицы DetailsList. Теперь из каждой таблицы, в
> которой требуется иметь Details я ссылаюсь на DetailsListId, по которому
> хранится набор необходимых дочерних записей.
>
> Так вот интересует: не изобретаю ли я велосипед, и нет ли для моей
> ситуации более проверенного решения. А ситуация, говоря кратко, такая —
> надо получить отношения многие:к-одному между таблицей Details
> ("многие") и большим количеством других таблиц БД.

Перефразируйте пожалуста яснее.

Здравствуйте, Other Sam, Вы писали:

OS>Перефразируйте пожалуста яснее.

А что конкретно не ясно?

Здравствуйте, _FRED_, Вы писали:

_FR>Так вот интересует: не изобретаю ли я велосипед, и нет ли для моей ситуации более проверенного решения.

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

_FR>А ситуация, говоря кратко, такая — надо получить отношения многие:к-одному между таблицей Details ("многие") и большим количеством других таблиц БД.

Повторяю свой вопрос: какие объекты предметной области (какой?) моделируют эти таблицы? Также неплохо привести текущую схему (ER).
Излишняя абстракция рождает непонимание.

Здравствуйте, wildwind, Вы писали:

_FR>>Так вот интересует: не изобретаю ли я велосипед, и нет ли для моей ситуации более проверенного решения.
W>Есть конечно, и не одно. Чтобы предложить подходящее, нужно прояснить твою ситуацию.

_FR>>А ситуация, говоря кратко, такая — надо получить отношения многие:к-одному между таблицей Details ("многие") и большим количеством других таблиц БД.
W>Повторяю свой вопрос: какие объекты предметной области (какой?) моделируют эти таблицы? Также неплохо привести текущую схему (ER).
W>Излишняя абстракция рождает непонимание.

Да ёлки-палки, какие могут быть варианты-то? Приведи ради интереса пару других, отличных

Например, есть таблица Заметки { NoteId, Note }, есть таблицы Товары, Служащие, Контракты, Адреса, … всё что угодно. Каждый Товар, Служащий, Контракт или Адрес может иметь несколько Заметок. Всё. Как?

Здравствуйте, _FRED_, Вы писали:

_FR>Например, есть таблица Заметки { NoteId, Note }, есть таблицы Товары, Служащие, Контракты, Адреса, … всё что угодно. Каждый Товар, Служащий, Контракт или Адрес может иметь несколько Заметок. Всё. Как?
Для такого сценария — по отдельной табличке типа OrderNodes, CustomerNodes etc (ID, %ParentTableName%_ID, Note).

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

Здравствуйте, Sinix, Вы писали:

_FR>>Например, есть таблица Заметки { NoteId, Note }, есть таблицы Товары, Служащие, Контракты, Адреса, … всё что угодно. Каждый Товар, Служащий, Контракт или Адрес может иметь несколько Заметок. Всё. Как?
S>Для такого сценария — по отдельной табличке типа OrderNodes, CustomerNodes etc (ID, %ParentTableName%_ID, Note).

А какой поинт в том, что бы дублировать структуру таблицы Notes? Я бы ещё немного понял таблицу OrderNodes (Id, OrderId, NoteId) и так далее, но это мне всё равно не нравится: количество таблиц увеличивается вдвое, причём половина таблиц имеет одинаковую структуру.

S>Для сценария, когда надо шарить один и тот же список между несколькими сущностями — ваш вариант.

Нет, списки шарить не нужно. Но, например, Адрес может иметь несколько наборов заметок: Заметки-об-адресе-в-целом, заметки-о-городе, заметки-об-индексе, заметки-об-улице…

> _FR>>Например, есть таблица Заметки { NoteId, Note }, есть таблицы
> Товары, Служащие, Контракты, Адреса, … всё что угодно. Каждый Товар,
> Служащий, Контракт или Адрес может иметь несколько Заметок. Всё. Как?
> S>Для такого сценария — по отдельной табличке типа OrderNodes,
> CustomerNodes etc (ID, %ParentTableName%_ID, Note).
>
> А какой поинт в том, что бы дублировать структуру таблицы Notes? Я бы
> ещё немного понял таблицу OrderNodes (Id, OrderId, NoteId) и так далее,
> но это мне всё равно не нравится: количество таблиц увеличивается вдвое,
> причём половина таблиц имеет одинаковую структуру.
>
> S>Для сценария, когда надо шарить один и тот же список между несколькими
> сущностями — ваш вариант.
>
> Нет, списки шарить не нужно. Но, например, Адрес может иметь несколько
> наборов заметок: Заметки-об-адресе-в-целом, заметки-о-городе,
> заметки-об-индексе, заметки-об-улице…

В вашем случае, чтобы получить 3ю нормальную форму придется делать так.

CREATE TABLE Addresses (
   AddressID integer PRIMARY KEY,
   Street text,
   City text,
);
CREATE TABLE Notes (
   NoteId integer PRIMARY KEY,
   Note text
);
CREATE TABLE AddressNotes (
   AddressID integer,
   NoteID integer,
   PRIMARY KEY (AddressID, NoteID),
   FOREIGN KEY (AddressID) REFERENCES Addresses (AddressID)
   FOREIGN KEY (NoteID) REFERENCES Notes (NoteID)
);
CREATE TABLE AddressStreetNotes (
   AddressID integer,
   NoteID integer,
   PRIMARY KEY (AddressID, NoteID),
   FOREIGN KEY (AddressID) REFERENCES Addresses (AddressID)
   FOREIGN KEY (NoteID) REFERENCES Notes (NoteID)
);
CREATE TABLE AddressCityNotes (
   AddressID integer,
   NoteID integer,
   PRIMARY KEY (AddressID, NoteID),
   FOREIGN KEY (AddressID) REFERENCES Addresses (AddressID)
   FOREIGN KEY (NoteID) REFERENCES Notes (NoteID)
);

Здравствуйте, _FRED_, Вы писали:

_FR>А какой поинт в том, что бы дублировать структуру таблицы Notes?
Те же, что и для любой нормализации.
Упрощаются запросы, работает быстрее (слегка), больше покрываемых юз-кейсов (например, легко можно выбрать все заметки заказчиков), проще в саппорте, исключаются сценарии дублирования — когда одна заметка навешена нескольким элементам, не смешиваются различные сущности.

Но это — когда данные обрабатываются влияют на БЛ. Если "только для показать" — лучше EAV'ом (псевдокод)-

CREATE TABLE dbo.ColumnAnnotations
(
  ID,
  TableObject_ID,
  TableColumn_ID,
  Table_ID,
  Note
)

+ check на (TableObject_ID, TableColumn_ID, Table_ID).

_FR>Нет, списки шарить не нужно. Но, например, Адрес может иметь несколько наборов заметок: Заметки-об-адресе-в-целом, заметки-о-городе, заметки-об-индексе, заметки-об-улице…
Ухх... Нда, это вообще оверкил выходит. Возвращаемся к чему пришли.

Здравствуйте, Other Sam, Вы писали:


OS>В вашем случае, чтобы получить 3ю нормальную форму придется делать так.

Нарушаете инвариант — одна заметка не может быть назначена более чем одной сущности.

Здравствуйте, _FRED_, Вы писали:

_FR>Например, есть таблица Заметки { NoteId, Note }, есть таблицы Товары, Служащие, Контракты, Адреса, … всё что угодно. Каждый Товар, Служащий, Контракт или Адрес может иметь несколько Заметок. Всё. Как?

А чем тут поможет еще одна таблица с ID заметок? Может сразу ссылаться на записи в таблице заметок?

Если количество заметок динамично для каждой сущности, то проще сделать через дополнительную таблицу для связи многие-ко-многим: EntitiesNotes (EntityId, EntityType, NoteId), где EntityType задается через where в селекте. Или чтобы отношения между таблицами не перекладывать на программистов, сделать по одному полю на каждый тип объектов: EntitiesNotes (ProductId, EmployeeId, ..., NoteId). Но тут неудобство в создании первичного ключа — надо вводить суррогатные NULL, плюс пересоздавать ключ при введении дополнительной сущности.