| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > Теоретический вопрос. Как правильно построить стру |
| Автор: buxNL 25.2.2006, 19:52 |
| Всем - здраствуйте, я - человек новый, так что пинайте меня без зазрения совести (на нужные ссылки). Итак: Вводная Есть объекты (много объектов) и их надо описать в БД помимо основных признаков (пара уровней, по которым можно сгруппировать более/менее эти объекты), у каждого может существовать куча признаков, которых или нет в множестве, или пару раз встречаются во всем множестве всех объектов. По самым скромным прикидкам, если завести на каждое необходимое свойство объекта - поле, то размерность таблицы в ширину станет больше количества строк, т.е в высоту.... Дополнительные условия По ходу поступления предложений и по ходу моих рассуждений Решение Не разумно заводить такое несметное количество полей. Что-то мне грезиться, что можно просто впихать все свойства в отдельную табличку, НО как в таком случае делать выборки по сходным полям.... т.е., если хоть у пары объектов (они могут быть в разных группах обоих уровней группировки) есть общий признак, то я эти объекты ОБЯЗАН выбрать простым SELECTом.... Даже более того - время от времени мне необходимо группировать ПО ВСЕМ признакам ВСЕ объекты. Знаю, тут должна быть другая логика, и другая математика.... Пинайте! Да... замена кучи полей на кучу таблиц - тоже... сомнительное решение... |
| Автор: Exception 25.2.2006, 22:31 |
| Можно примерчик? |
| Автор: igon 26.2.2006, 04:18 |
| Попробуй посмотреть в сторону отношения "многие-ко-многим". Кроме таблиц "Объекты" и "Свойства" нужна будет еще одна - кроссировочная, с двумя полями, ID_Объекта и ID_Свойства. |
| Автор: buxNL 26.2.2006, 16:25 | ||||
Да, пожалуйста: Id 0001 Объект | cтепень мохнатости (код из таблицы мохнатости) | вид ножки (код из таблицы вид ножки) | далее еще с десяток всяческих полей Id 0002 Объект2 | твердость (код из таблицы твердости) | ворсистость (код из таблицы вид ворсистости) | далее еще с десяток всяческих полей Id 0003 Объект3 | твердость (код из таблицы твердости) | волокнистось (код из таблицы вид волокнистости) | далее еще с десяток всяческих полей и т.д. Где-то 600 объектов с такими расплывчатыми признаками. База будет расти. Пару обязательных полей, которые есть у всех объектов, и которые поддаются систематизации - я не показываю, ибо с ними все просто. Пользователю по запросу из базы необходимо будет выбрать все объекты, у которых, к примеру значение твердости описывается (имеет не нулевое значение), и может быть сразу, а может быть и после первого запроса - объекты имеющие определенное значение твердости. Тупое решение, сделать так Объект | cтепень мохнатости (код из таблицы мохнатости) | вид ножки (код из таблицы вид ножки) | твердость (код из таблицы твердости) | ворсистость (код из таблицы вид ворсистости) | волокнистось (код из таблицы вид волокнистости) | и т.д., не забывайте, что объектов более 600 и полей у каждого до 10 миниумум. Что самое досадное - поля могут повториться как у Объекта3 и Объекта2 - поле твердость. И это важно, основные запросы будут именно на выборку похожих элементов =(((((((((((( Добавлено @ 16:26
Да, мне так подсказывали уже сделать. Видимо это единственный верный вариант ? |
| Автор: buxNL 26.2.2006, 16:44 |
| Вот читаю http://www.helloworld.ru/texts/comp/other/oop/ch04.htm Буч Классификация Существует ОБъектно Ориентированные БД ? |
| Автор: buxNL 26.2.2006, 19:17 |
| Люди :cry: , есть-ли опен аналог Caché http://www.intersystems.com/cache/index.html ??? Я понимаю - можно в реляционную модель при желании все что угодно загнать...... Но, вот что еще Сaché enables rapid Web application development, extraordinary transaction processing speed, massive scalability, and real-time queries against transactional data - with minimal maintenance requirements. И это очень... даже очень... Это видимо, то - что доктор прописал.... но.... |
| Автор: LSD 26.2.2006, 20:25 | ||
| Существуют, но не работал поэтому ничего про них не скажу. Есть ORM (Object-Relational mapping) средства для обычных СУБД (только тот маппинг который они тебе предложат будет не лучше того что ты сделаешь сам). У меня следующий вопрос, ты говорил, что признаков может быть очень много. И в тоже время в твоем примере:
значит таблиц с ворсистостью, твердостью у тебя тоже будет очень много (по одной на каждый тип свойства), или я чего-то не понимаю? |
| Автор: buxNL 27.2.2006, 09:57 | ||||||
Я уже немного поковырял тему.... да - линк-базу или как ее там буду сам делать скорее всего.... Не думаю, что мне нужно универсальное решение, достаточно будет отразить только этот мой специфический случай....
Нет, таблицы с восистостю, твердостью - будут по одной, я просто не знаю как грамотно это показать. Есть идея - свалить их в одну большую таблицу атрибутов, ворсистость (точнее - код атрибута ворсистость) | повышенная ворсистость (точнее - код атрибута ворсистость) | пониженная ворсистость (точнее - код атрибута ворсистость) | нестандартная ворсистость (точнее - код атрибута ворсистость) | bla-bla-bla-bla ворсистость (точнее - код атрибута ворсистость) | bla-bla-bla-bla ворсистость (точнее - код атрибута ворсистость) | bla-bla-bla-bla твердость (точнее - код атрибута твердость) | мягкая твердость (точнее - код атрибута твердость) | среднеяя твердость (точнее - код атрибута твердость) | твердая твердость (точнее - код атрибута твердость) | очень твердая твердость (точнее - код атрибута твердость) | bla-bla-bla-bla твердость (точнее - код атрибута твердость) | bla-bla-bla-bla и.т.д. Вот здесь я пока не знаю - стоит -ли подобную таблицу приводить к нормальной форме и порождать кучу мелких таблиц на значение каждого аттрибута.... Вот и все вместе будет выглядеть так: Объект <-> кросс таблица <-> таблица атрибутов (пока ненормализованная) В кросс таблице - соотвествие кода ID объекта к ID атрибутов и кокректное значение самого атрибута. т.е. вот так oбъект ID | атрибут ID | какое-то одно значение атрибута (код) из таблицы | либо будет oбъект ID | атрибут ID + какое-то одно значение атрибута (код) из таблицы | 001 | 301255 где 001 ID oбъекта, 301 ID атрибута, 255 ID значения атрибута но так не хочется, ибо нарушение всех правил и в дальнейшем будет геморой. |
| Автор: Akina 27.2.2006, 10:47 |
| Гм... я бы делал так: Объекты (primary key = ID_O): ID_O прочие поля Категории атрибутов (primary key = ID_K): ID_K Название категории прочие поля Атрибуты (primary key = ID_K + ID_A): ID_A ID_K Содержание атрибута прочие поля Кросс-таблица (primary key = ID, indices ID_O (1), ID_K+ID_A (2)): ID ID_O ID_K ID_A |
| Автор: buxNL 27.2.2006, 11:00 |
| Стало-быть рекомендуешь привести к нормальному виду, ok! Всем спасибо огромное, так и сделаю в итоге !!!!! УРА |