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Признайтесь честно, вы выпиваете?
Крайне редко, а что?
Вас заинтересовали модели данных?:)

ViPRosolap4ik,
остальные често сказали , что не понимают (ну, хотя бы зачем это надо)
а ты вот влез чего?
Потому что тоже не понимает, но вот в такой форме:)
А цель предельно проста - свести к минимуму программирование приложений за счет "соединения" концептуальной модели и логической.

ViPRosСамая подлая вещь в СКЛ - конструкция FROM. Типизированные Связи и Роли в Отношениях позволяют FROM перевести в разряд опциональных хинтов.
Результатом запроса к БД должна быть подсхема схемы БД со всей присущей БД семантикой, а не какое-то бессмысленное "отношение", с которым работают "математики" (а не пользователи).
Так что, например, для схемы БД из двуз объектов, связанных М:М

Человек (A) <-- Работает в/В которой работает (1) -->Организация (B)

запрос к этой схеме должен иметь примерно такую FROM:

FROM A-1-B

(где A и B - идентификаторы объектов, 1 - номер связи).

ViPRosБредятина,

нет. From должен присутствовать только для улучшения производительности.
А запрос должен имет семантику типа ТипСвязи1(А (или*) в Роли1 , B (или *) в Роли2)

Тут ТипСвязи1 = Работает.
Роль1 = Работник
Роль2 = Огранизация

ТИпСвязи! могла бы классифицировать N связей и мы бы обошлись без явного перечисления UNION и приведения атрибутов (если бы Атрибуты были типизированы).

FROM Требует знания логической структуры.
Иммутбельность тут не причем.
Тоже нет:)
Я объясняю азы классической объектной модели данных, и использовал FROM для преемственности и понимания теми, кто знаком с FROM, только и всего.
Никакого отношения к производительности FROM не имеет.

Результатом запроса должна быть таже схема
Человек (A) <-- Работает в/В которой работает (1) -->Организация (B)
с, возможно меньшим количеством экземпляров объектов Человек (именно, Человек, а не Работник:)) и Организация, чем количество экземпляров в БД.

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

Хотя правильнее было бы, конечно, вернуться к теме, так как реализация классификатора, как типа характеристики (наборы-то давно реализованы) - это, дествительно, важное неправление:)

ViPRosViPRos,

Никаких FROM
Так их, проклятых!

Например:

FOR подсхема данных
SELECT ...

Никаких FROM:)

ViPRosНе надо КАК, не надо ОТКУДА
Только ЧТО
Ну, хорошо:)

[quot guest_20040621]> азы классической объектной модели данных

Вам, наверное, забыли рассказать, что объектной модели данных в природе не существует. И, наверное, забыли рассказать, что семантические отношения где бы то ни было сами по себе ниоткуда не возникнут.

Модератор:

aikusНемного про сет енум, я их когда то применял по двум причинам:
1. было лень или некогда писать отдельную табличку.
2. наивно думал, что данного набора хватит.
теперь про недостатки: 1 причина убога в корне, 2 - на самом деле очень часто приходилось добавлять значения, а т.к. эти значения добавляются не прозрачно, то возникают опасность появления ошибок.

Вы просто, пока, не поняли до конца о чем речь, но это нормально.
1 - это у вас бесполезный субъективный аргумент; супертип "набор" (кодов, строк, чисел) часто используется, и, очень часто, наиболее удобен;
2 - значения в набор постоянно добавляются, а не очень часто.
aikusТеперь немного про бредятину:
Сразу признаюсь, что я ни чего не понимаю из описанного вами.

Это я понял, не Вы один:) Но Вы и вопросов никаких не задаете. Я то все это понял тридцать лет назад, и мне довольно трудно понять, как можно не понимать такие очевидные вещи:)
aikus1. То что вы описываете в примере человек <-> работа в принципе укладывается в обыкновенный триплет, а таких баз в своё время натворили уже достаточно.

Это просто подтверждает, что Вы ничего не поняли:) Но это не беда.
aikus2. Вероятно вам что-то даст neo4j
:)

Модератор: граждане Бредятина и guest_20040621 , если вам есть что рассказать друг другу, высказывайтесь по существу

Роман ДынникБредятина,
По-моему, проблема в том, что вы свои мысли не можете чётко формализовать, по-этому их ход никто не понимает.

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

Немного не точно. Есть записе-ориентированные (например, "реляционные", в которых отсутствуют идентификаторы экземпляров объекта, но есть ограничения целостности в виде "ключей", которые находятся среди прочих характеристик объекта) и объектно-ориентированные (в которых, идентификаторы экземпляров есть, и находятся вне характеристик экземпляра объекта). Не нужно ничего выносить, так как это здесь никого не интересует. Поэтоу я Вам и предложил вернуться к "наборам" и "классификаторам". Впочем это тоже вряд ли кого интересует:)
Роман Дынник...Приведите пример (кусок диаграммы), что вы понимаете под концептуальной моделью без связей?
Это еще что такое "концептуальная модель без связей"???

guest_20040621> азы классической объектной модели данных

Вам, наверное, забыли рассказать, что объектной модели данных в природе не существует. И, наверное, забыли рассказать, что семантические отношения где бы то ни было сами по себе ниоткуда не возникнут.

Ник - со смыслом. Редкостный бред.

То есть, уважаемый модератор с этим согласен? Мне забыли что-то рассказать, и я говорю редкостный бред?
Ну что же я это учту, конечно:)
Модератор: это личное мнение автора по теме

Роман ДынникЯ об этом:
БредятинаА цель предельно проста - свести к минимуму программирование приложений за счет "соединения" концептуальной модели и логической.
Вы можете привести пример концептуальной или логической модели без связей?

Вы не понимаете сути вопроса, к сожалению. Где Вы видите в моей фразе о том, что концептуальная модель должна стать логической, хоть слово о "связях"???
Если уж Вы говорите о связях, в концептуальной модели связи есть, а в логической - нет. Но, поскольку Вы не понимаете даже абсолютно ясное определение связи, то, конечно, путаетесь с концептуальной, логической, связями...
Роман ДынникВы хорошо понимаете разницу между концептуальной моделью И логической и для чего они нужны?
Безусловно, я понимаю не просто хорошо, а, к великому сожалению, очень хорошо:)
И, конечно, в результате, то, что я говорю - это редкостный бред:)

ViPRosРоман Дынник,

я воще то думал что Бредятина злится на Отсутствие связей в РСУБД :)
:) злится - это сильно сказано... связи отсутсвуют во всех известных ЛОГИЧЕСКИХ моделях данных, кроме классической объектной модели данных, которая является и концептуальной, и логической, и позволяет создавать приложения с минимальным программированием

guest_20040621> не могу фиксировать в faq то, что не соответствует действительности

То есть модератор не понимает разницы между моделью и моделью данных? Потрясающе. Ладно, "разработку с разных концов" я еще мог списать на отсутствие опыта разработки информационных систем. Но непонимание фундаментальных основ - это нонсенс.
"Непонимание фундаментальных основ":) Сильно:)

Дэйт:
"Из изложенного выше не совсем ясно, является ли ER-модель на самом деле моделью данных, по крайней мере, в указанном в настоящей книге смысле (т.е. формальной системой, включающей структурные аспекты, а также аспекты поддержания целостности и манипулирования данными)."

Итак:
1) Надо же так изложить, чтобы было не совсем ясно:)
2) Модель данных бывает в разных смыслах:)

Ну а главное - классическая объектная модель данных является моделью данных абсолютно во всех смыслах, в том числе и в смысле, изложенном в книге Дейта (так как, конечно, является формальной системой, включающей структурный аспект, аспект целостности, аспект манипулирования). А вот РМД, как хорошо известно, формализована крайне плохо, и до модели данных, все-таки, не дотягивает. Но не стоит это фиксировать в faq, пожалуй, чтобы не расстраивать такое большое количество людей:)

Дейт:
"Идеи семантического моделирования могут быть полезны как средство проектирования базы данных даже при отсутствии их непосредственной поддержки в СУБД."

Что уж говорить при присутствии их непоредственной поддержки в СУБД:)