|
| |
|
|
| |
для: Mookapek
(11.08.2009 в 01:17)
| | | можно изменить структуру так, чтобы типы оказались разными. | |
| |
|
|
| |
|
|
| |
для: Mookapek
(01.08.2009 в 01:36)
| | | Кстати, у такой структуры, как мне кажется, есть существенный недостаток: значения val всех опций из таблицы options будут одного и того же типа данных. | |
| |
|
|
| |
|
|
| |
для: Mookapek
(06.08.2009 в 19:00)
| | | >если требуется вывести все объекты недвижимости и их характеристики, то производится сначала запрос к таблице objects, а потом запрос к таблицы harakteristiki.
Не обязательно. Таблицы в запросе можно соединить. | |
| |
|
|
| |
|
|
| |
для: Mookapek
(01.08.2009 в 01:36)
| | | У меня вопрос по данной схеме: если требуется вывести все объекты недвижимости и их характеристики, то производится сначала запрос к таблице objects, а потом запрос к таблицы harakteristiki. Т.е. общее количество запросов будет равно количеству объектов + 1. Не будет ли это большой нагрузкой на сервер? | |
| |
|
|
| |
|
|
| |
для: serjinio
(03.08.2009 в 10:31)
| | | сущности добавляет разработчик, а не клиент.
Клиент добавляет объекты.
Так вот, данная схема не позволяет добавлять такие объекты, потому что отвлеченная сущность "арендуемый объект" в ней не заложена.
А так в принципе, конечно, имеет право. | |
| |
|
|
| |
|
|
| |
для: Trianon
(03.08.2009 в 09:58)
| | | естественно если добавляется новая сущность то под нее создается своя таблица с характеристиками..
но ТС писал Хм... если у меня есть три объекта - квартира, коттедж, земельный участок. те автоматом новая сущность не предусматривалась... | |
| |
|
|
| |
|
|
| |
для: serjinio
(03.08.2009 в 06:57)
| | | И как клиент в рамках этой схемы сможет добавить пару тройку офисов, складов, ангаров? | |
| |
|
|
| |
|
|
| |
для: Trianon
(30.07.2009 в 17:54)
| | | Почему ? вот выдержка из www.microsoft.com/sql
Преобразование логической модели в физическую
При переходе от логической модели к физической сущности преобразуются в таблицы,
а атрибуты — в поля (столбцы).
Отношения между сущностями можно преобразовать в таблицы или оставить в виде внешних ключей.
В процессе проектирования физической базы данных необходимо соблюдать ряд общих правил:
# Каждая таблица должна иметь уникальный идентификатор (первичный ключ).
# Все данные таблицы должны относиться к одной сущности.
# Желательно избегать атрибутов, способных принимать неопределенные значения.
# Таблица не должна содержать повторяющихся полей.
|
1 таблица (Сущности)"Квартира", "Коттедж", "Земельный участок"
2 таблица (данные "Квартира") "Адрес", "Цена", "Кол. комнат"
3 таблица (данные "Коттедж") "Адрес", "Цена", "Кол. комнат", "Площадь участка"
4 таблица (данные "Земельный участок") "Адрес", "Цена", "Площадь участка" | |
| |
|
|
| |
|
|
| |
для: Mookapek
(28.07.2009 в 23:19)
| | | А что можно сказать про такую структуру базы данных? В чем минусы?
три таблицы:
первая - просто ид объекта
вторая - список всевозможных свойств
третья - значения свойств для конкретного объекта
Object
+-------+
|id_obj |
+-------+
| 1 |
+-------+
Options
+------+---------+
|id_opt| name |
+------+---------+
| 1 | Адрес |
| 2 | Площадь |
| 3 | Цена |
+------+---------+
Values
+--------+--------+----------------------------------+
| id_obj | id_opt | value |
+--------+--------+----------------------------------+
| 1 | 1 | г. Москва, Измайловский пр.2, 15 |
| 1 | 2 | 100 кв.м. |
| 1 | 3 | 500 000 $ |
+--------+--------+----------------------------------+
|
| |
| |
|
|
| |
|
|
| |
для: Trianon
(01.08.2009 в 01:47)
| | | >Из меня риэлтер никакой. Поэтому не представляю, чем там они свои объекты идентифицируют.
Там это выглядит вот так. | |
| |
|
|
|
