| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > как реализовать отношение многие ко многим |
| Автор: megaproger 30.8.2006, 12:37 |
| Есть 4 таблицы: Таблица А: ID - первичный ключ Value - булевы данные Таблица B: ID - первичный ключ Value - числовые данные Таблица C: ID - первичный ключ Value - строковые данные Таблица Б-отношения ownerId - Id из одной таблицы -любой (А или B или С) parentId - Id из другой таблицы -любой (А или B или С) Как мне правильно организовать отношения между этими таблицами? какие связи использовать? может нужны какие то дополнительные таблицы? |
| Автор: Akina 30.8.2006, 12:42 |
| Первое что зрится - это не (ownerId + parentId), а ((ownerId + ownerTable) + (parentId + parentTable)). Второе - слить таблицы A,B,C в одну типа (ID, ValueBool, ValueNum, ValueStr). Выбирай. А мож еще что придумается. |
| Автор: LSD 30.8.2006, 12:44 | ||
Можно создать таблицу Б в таком формате:
и определить constrain, что только одно поле для каждой группы может быть заполнено. |
| Автор: DeadMan 30.8.2006, 12:46 |
| на вскидку 3 решения первое в таблицу Б ввести еще одно поле - писывающее откуда беруться данные (1 - AA 2- AБ.....) второе в таблице Б 6 форен кеев OwnerA OwnerA OwnerA ParentA ParentB Parent C (все могут быть Null) третье все сделать в одной таблице Id BoolValue (может быть Null) IntValue (может быть Null) StringValue (может быть Null) ParentId - ссылка на Id из этой же таблицы |
| Автор: Akina 30.8.2006, 13:39 |
| Мне на самом деле навылет неясна логика создания 3 разных таблиц, хранящих данные одной сущности, кои различаются только типом данных. Гораздо логичнее была бы одна таблица со строковыми данными - ибо преобразование строки в число или булев тип, а равно и обратно, не должно вызывать проблем. А для отбора данных одного исходного типа ввести дополнительное поле. |
| Автор: DeadMan 31.8.2006, 13:44 | ||
а если надо посчитать сумму чисел (а у тебя в поле и числа и були и строки) |
| Автор: Akina 31.8.2006, 14:59 | ||||
|
| Автор: LSD 31.8.2006, 22:01 |
| Akina 1. Это медленней т.к. идет преобразование типов. 2. Пример явно демонстрационный и в реальной БД скорее всего будет не одно поле, а набор совершенно разных полей, плюс возможно внешние ключи из/на другие таблицы. Так что думаю вопрос имеет право на существование, именно как академический: "А как можно реализовать подобные отношения?". |
| Автор: Akina 31.8.2006, 22:55 | ||
Понимаешь, я отношусь к этому так - сперва что-нить сделаем, а потом придумаем для чего мы это сделали. И будет у нас повод гордиться. Сорри за оффтоп. |
| Автор: megaproger 1.9.2006, 09:14 |
| А всё таки , что будет оправданее? Использовать три столбца в одной таблицы с разными типами ИЛИ использовать один строковый столбец и при помощи встроенных функций СУБД осуществлять приведение типов. Прошу высказать оценку с разных критериев: - с точки зрения избыточности БД - с точки зрения дискового пространства ,занимаемого таблицами(будут ли занимать место столбцы со значением Null?). - с точки зрения быстродействия sql-запросов, если предполагается, что объем такой таблицы может быть более миллиона записей.И надо будет делать выборку и какие то статистические подсчеты по числовым типам. |
| Автор: LSD 1.9.2006, 10:24 | ||||
NULL значения занимают минимум дискового пространства (1-2 байта, в зависимости от СУБД). Хранение же например даты-времени в строке, будет требовать больше места чем в виде TIMESTAMP. Плюс гарантируется некая целостность данных, т.е. столбец NUMEBER всегда хранит только числа, и записать туда строку не удастся.
Естетсвенно что необходимость преобразования типов на миллионах записей, потребует больших вычислительных мощностей. А вообще ты и сам можешь это проверить. |
