БД и хранение разнородных данных
Как можно хранить в БД кучу разнородных данных?
Например, информацию об автомобилях и квартирах. У каждого из этих типов есть свои параметры. Например, у машины параметры: год выпуска, пробег по РФ, общий пробел, объем движка, цвет, кузов, тип автомобиля и т.д. У квартиры: год постройки, год капремонта, количество комнат, этаж, площадь кухни, общая площадь, жилая площадь, санузел - раздельный/совмещенный, дом - панельный/кирпичный... и т.п. Как все это можно хранить в базе данных, так, чтобы красиво было?
Главное - как хранить в БД, чтобы не сильно загаживать ее пустыми полями. Т.к. если хранить всю информацию в одной таблице, будет много лишних (пустых) ячеек в таблицах.
Т.е. первая строка - автомобиль. Заполнены только автомобильные ячейки, остальные пустые.
Вторая строка - недвижимость - заполнены только ячейки по недвижимости, остальные свободные.
Грязно получается.
А делать разные таблички для разных объектов - тоже можно утомиться, т..к нужно вести общий учет объектов. Можно считать, что объект - это объявление в газете.
Т.е. прошу ответить, как бы вы реализовали данную задачу. При том, что типы объектов могут быть не только машины и квартиры, но и много другое - электроника, бытовая техника, турпоездки, вакансии, резюме и т.д.
Спасибо.
Кстати, теорию баз данных читал дважды в разное время, так что к ней можно не отсылать.
1. Имена полей
ID (счётчик) | ИМЯ_ПОЛЯ (строка)
2. Значения полей
ID_ОБЪЕКТА | ID_ПОЛЯ | ЗНАЧЕНИЕ
А далее делается перекрёстный запрос...
Соответственно, если имеем 30 объектов, то получается 900 записей. Я правильно понимаю?
Если ты действительно занимаешься разработкой соответствующего СУБД, то БД у тебя получится мягко говоря 'большая'. Под 'большой' имею ввиду не размер таблиц, а количество таблиц с множественными связями. Без соответствующих знаний ты просто не осилишь!! Лучше потрать время на прочтение хоть какой-нить литературы по БД, а потом в бой..
Кстати, теорию баз данных читал дважды в разное время, так что к ней можно не отсылать.
Читал, как я уже говорил. Это написано в самом первом посте. Вот и спрашивал, есть ли другие мысли по этому поводу? Естественно, понимаю, что если нет мыслей, придется так и делать. Но иногда находятся интересные и грамотные выходы из сложившейся ситуации. Взять, например, то, как хранит данные гугл - нестандартный ход. Вот и я тоже ищу нестандартный ход.
Есть очень интересная штука, стандартизированная W3C - XML Schema. Oracle и микрочлены реализовали её поддержку в своих СУБД. Называть XML-базой (как у Oracle) её не совсем верно, т. к. XML является лишь средством описания данных.
А что-нибудь про поле "XML-данные" в MS SQL не использовали?
А что-нибудь про поле "XML-данные" в MS SQL не использовали?
Не знаю, как у микрочленов, работал только в Oracle. Вначале надо зарегистрировать схему средствами пакета <не помню>, после чего XML-схема транслируется в объекты и не хранится в виде текста, что ускоряет доступ, позволяет использовать индексы и т. п.
Это имелось в виду под "истиностью"?
http://xml.nsu.ru/extra/database_6.xml
Фу, ужас. "Референциальная интегрированность" :(. Текст явно переводили рекламщики, хоть и выложен на серьёзном сайте. Всё сказанное в писульке относится к Oracle.