mr_maxПодскажите как лучше спроектировать
есть таблица групп
id,name,description

И есть категории

одна группа может содержать несколько категорий, как сделать

добавить поле с типом set в таблицу группу или сделать отдельную таблица соотношения группы и категорий.

__________________________________________________________________
THE TRUTH IS OUT THERE

Если "категорий" у "групп" мало и они не имеют никаких свойств, то можно использовать набор. Но не строк, а кодов. В этом слочае у элемента набора есть код и наименование (в БД хранится код).

Роман Дынникесли я правильно понял вопрос, то здесь enum flags можно использовать для задания списка.
А поле в БД было бы типа int. (Я тоже не знаю какие СУБД поддерживают поле типа set?)

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

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

...enum datatype нашел только в MySQL и Postgre
где еще есть? ORACLE/MSSQL/SYBASE?

p/s/ действительно интересно!
Нет, не шутка. Просто получается, что СУБД пока не создана. Но и это не шутка:)

SERG1257Роман Дынник bit может принимать значения 0, 1, null. Как правило этого явно недостаточно
http://msdn.microsoft.com/ru-ru/library/ms177603.aspx

Роман Дынникне будет ни вложенных запросов, ни join, ни накладных расходов с парсингом списка передаваемого одним параметром, и используемого в условии выборки.ни индексов

а в остальном никакие накладные расходы не стоят запутывания логики программы. В проектах, с тяжелыми базами (где стоит экономить каждую копейку производительности) так же много разработчиков вовлечено и одна маленькая ошибка или время на вникание перевешивают возможную выгоду одного поля против 16.

Поддержка рассматриваемых типов не имеет к этому никакого отношения. Классификатор должен быть типом характеристики (свойства, атрибута), а не отдельным классом (отношением, ...). Это намного эффективнее для решения многих задач.
В MS нет специалистов, которые бы в этом хоть немного разбирались..

Роман Дынник БредятинаКлассификатор должен быть типом характеристики (свойства, атрибута), а не отдельным классом (отношением, ...). Это намного эффективнее для решения многих задач.
В ряде задач - возможно, но не во многих.


Как же не во многих. Это "проблема" имеет ясное теоретическое обоснование, на которое я уже много раз обращал внимание. Повторю коротко.

Когда вы вводите для конкретного экземпляра (кортежа) объекта (класса, отношения) Человек значение "Петров" характеристики (свойства, атрибута) Фамилия [тип - строка], Вы, тем самым, относите этого конкретного человека к классу людей, имеющих фамилию "Петров".

Когда вы вводите для конкретного экземпляра того же объекта значение "1976" характеристики Год рождения [тип - целое число], Вы, тем самым, относите этого конкретного человека к классу людей, родившихся в 1976 году.

И т.д.

Такоим образом, ВСЕ характеристики (свойства, атрибуты) используются для классификации экземпляров. Разве не забавно, что СОБСТВЕННО КЛАССИФИКАТОРЫ ПРИ ЭТОМ НЕ ПРЕДСТАВЛЯЮТСЯ С ПОМОЩЬЮ ТИПОВ ХАРАКТЕРИСТИК?

Роман ДынникБредятинаВ MS нет специалистов, которые бы в этом хоть немного разбирались..
А где есть? В Caсhe ) ?

Возможно, Вы имели в виду IS, а не Cache:) Нет, у них тоже нет.

Напомню, что другой непреодолимой "проблемой" для коммерческих разработчиков является реализация связей между объектами. Связи не удалось, пока, реализовать ни в одной коммерческой СУБД.

SERG1257Бредятина Связи не удалось, пока, реализовать ни в одной коммерческой СУБД.Смелое заявление. Подкрепить бы его вашим определением связи, а так же пояснением на языке ЖЭКа чем не устраивает ограничение внешнего ключа.
Да и пример с Человеком тоже какой то туманный.


Это не заявление а факт. Хорошо известный, вообще-то.
Ограничения целостности - это не связи, как это можно не понимать:)
Если уж Вы вспомнили о "ключах", то есть, фактически об РМД, то напомню, в очередной раз, что в РМД нет ни объектов, ни связей между объектами. В ранних работах Кодд применял термины "отношение типа сущности" и "отношение типа связи", но все это не ужилось с алгеброй, и осталось только на бумаге. Остались просто "отношения", а связи реализуются всеми как попало на уровне приложений (так как на уровне СУБД их нет). Я уже неоднократно пояснял, как можно реализовать связи в продукте, который принято называть "реляционная СУБД".
Нет связей и в "постреляционных" СУБД, например, в Cache. Там есть, в зависимости от "уровня" доступа:
1) либо глобалы;
2) либо классы;
3) либо те же "отношения".
Связь не может быть представлена с помощью класса (в "объектно-ориентированной" СУБД) или с помощью отношения (в "реляционной" СУБД), и я это тоже неоднократно показывал...

"Пример с Человеком" - яснее некуда:) Он не имеет отношения к связям, а имеет - к "проблеме" классификаторов. Вы, видимо, просто не вникли, пока.

SERG1257IMHO подавляющее большинство проблем в софтостроении вообще и в СУБД в частности, в том что программы не делают то что нужно заказчику и делают то что ему не нужно, впустую (для заказчика) расходуя ресурсы. Ответственность за это несут и аналитик не понявший заказчика, и заказчик поменявший правила игры и девелопер делающий "круто" - универсально, оптимизированно или еще как, а чаще интегратор - молотком загоняющий имеющийся софт в прокрустово ложе требований заказчика.

Конечно, конечно. Именно потому, что нет возможности реализовать концептуальную модель непосредственно. Я Вам это и объясняю... С разных сторон:)

Роман ДынникЗанимаетесь структурой и алгоритмами сетевых БД?
Если, да, то для каких целей/проектов?


Занимаюсь моделями данных, теорией и проектированием БД. Для разных проектов.

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


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

Я Вам советую вернуться к "сложному" типу характеристики объекта "код", у которого два атрибута: код и наименование (в отличие от "простого" типа "строка", у которого только наименование). Это уже давно используется в СУБД, и является прообразом типа "классификатор".

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

33/Петров/мужской

то есть, и Фамилия и Пол стали просто строками, оставаясь при этом оба, фактически, классификаторами людей.

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

Роман Дынник...По связям абсолютно солидарен с SERG1257 . Хотелось бы узнать...

Приветствую это желание:)

SERG1257 Подкрепить бы его вашим определением связи...
Только сейчас обратил внимание на эту странную фразу - можно подумать, что существует какое-то формальное определение связи между объектами, кроме определения в рамках классической объектной модели данных, которое Вы назвали "моим". Напомню:

Связь (между объектами) - объективная особенность совместного существования двух, и только двух, независимых объектов (назовем их условно "первым" и "вторым"), характеризуемая мощностью и семантикой , как со стороны первого объекта по отношению ко второму, так и со стороны второго объекта по отношению к первому.

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

Семантика связи - качественный атрибут связи между объектами, объясняющий смысл связи со стороны одного объекта по отношению к другому объекту.

Очевидно, что связь - это не объект, и, тем более, не характеристика объекта. Например, в РМД отношения и ключи - это, конечно, не связи. Их можно только интерпретировать как "связи" на уровне приложения. Это, впрочем, подтверждается и тем поверхностным, неформальным определением связи, которое можно найти в основополагающей статье Чена: "Связь есть ассоциация между сущностями". В своей критике интерпретации Ченом понятий "сущность" и "связь" на стр. 555-556 8-го издания "Введение в системы баз данных" Дейт обращает внимание на то, что связь по Чену - это не сущность (и наоборот), но пишет, что в статье Чена все это определено и разъяснено не очень четко. Кстати, перевод определения Чена на стр. 538 упомянутой книги Дейта окончательно запутает многих читателей:)

Роман ДынникФормально, в ооп, объекно-ориентированных языках и т.п. (и даже функциональных), когда мы попадаем в исполняющую среду , связь между объектами определяется ссылкой на адрес в памяти/управляемой и неуправляемой куче, что своего рода также является ключом/кодом.
Также можно сказать что и связи между объектами определены программно - вызывается либо dispose в неуправляемых языках, либо за уничтожение объектов отвечает сборщик мусора в управляемых средах - достаточно прочитать как он работает в java или .net, как выделяется память в куче и как она освобождается.

Опять какое-то недоразумение. ООП не имеет никакого отношения к БД. Я вообще ничего не говорю ни о каком программировании, ни о структурном, ни о процедурном, ни о деклативном, ни об объектно-ориентированном. А Вы зачем-то о программировании заговорили. Моя цель - прекратить программирование приложений. И классическая объектная модель данных, абсолютно никак не связанная с ООП, в значительной степени, служит достижению этой цели.
Также можно сказать что и связи между объектами определены программно - вызывается либо dispose в неуправляемых языках, либо за уничтожение объектов отвечает сборщик мусора в управляемых средах - достаточно прочитать как он работает в java или .net, как выделяется память в куче и как она освобождается.
Роман ДынникЗдесь можно было бы еще процитировать Кнута и теорию списков/графов, но я не буду :)
Ясно что между объектами (а также даже между объектом и свойствами определяемыми значимыми типами {int, bool...}) в любой исполняемой среде есть вполне определенная связь, и она не мифическая!

Вы о чем-то о своем, о программистском:) Я уже говорил, что "современные" СУБД ("реляционные", "постреляционные") нужны для борьбы с безработицей, чтобы вместо простого создания приложений, кто-то занимался бы "определенными связями между объектами в исполняемой среде", и программировал, программировал, программировал...:)
Роман ДынникЯ, честно говоря, уже перестал понимать о чем разговор )
А я думаю, даже и не начинали:)
А разговор был о реализации таких типов характеристик, как "набор" и "классификатор":)

olap4ikПризнайтесь честно, вы выпиваете?
Крайне редко, а что?
Вас заинтересовали модели данных?:)