 |
|
Модераторы: LSD |
 
|
|
идеологический вопрос? 
| leniviy |
|
|||
 Опытный  Профиль Группа: Участник Сообщений: 552 Регистрация: 8.2.2003 Где: Спб Репутация: нет Всего: 5 |
Добрый день! Ситуация следующая: в СПб есть примерно 5 млн квартир, 10 млн комнат и 1 млн нежилых помещений. Я тут с пеной у рта доказываю сослуживцам, что лучше их держать в разных таблицах, чтобы
а) поиск по квартирам был быстрее б) чтобы не дай бог не привязалась коммерческая аренда к квартире или человек не прописался в универсаме в) чтобы пользователь в разных гридах мог посмотреть и людей и фирмы в конкретном доме Они же мне говорят, что все похожие объекты надо хранить в одной таблице, чтобы а) таблиц было меньше
б) всё можно было бы привязать ко всему в) неуч пользователь в ОДНОМ гриде мог посмотреть и людей и фирмы в конкретном доме я устал спорить уже. мне не хватает аргументов, а может я не прав. Какие у вас мысли? |
|||
|
||||
Загрузка ...
| skyboy |
|
|||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
а пошире условие расписать можешь?
|
|||
|
||||
| bas |
|
||||||||||
|
Опытный Профиль Группа: Участник Сообщений: 446 Регистрация: 14.8.2002 Где: Молдова, Кишинев Репутация: нет Всего: 2 |
Для этого можно и нужно ставить признак (коммерческая площадь, аренда, жилье ..... )
Запрос с условием из предыдущего пункта.
Таблиц должно быть достаточно, но не избыточно.
Желательно , но не обязательно. Все зависит от задачи. И что понимаеться под обьектом (кв.метр,комната, помещение, квартира, дом .....)?
Это сообщение отредактировал(а) bas - 3.7.2006, 14:18 |
||||||||||
|
|||||||||||
| leniviy |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 552 Регистрация: 8.2.2003 Где: Спб Репутация: нет Всего: 5 |
ну есть общие данные:
адрес дома, номер помещения, площадь, телефон, этаж, высота потолка есть данные касающиеся только квартир: жилая площадь, площадь ванной, туалета, кухни, к-во комнат, материал стен комнат: пл. балкона есть привязка: к квартирам - люди и комнаты к нежилым - фирмы как эта инфа должна показываться, заказчик предоставил решать нам. |
|||
|
||||
| bas |
|
||||
|
Опытный Профиль Группа: Участник Сообщений: 446 Регистрация: 14.8.2002 Где: Молдова, Кишинев Репутация: нет Всего: 2 |
На вскидку - жилые помещенния (в том числе используемые фирмами как оффисы и произодственные помещения) в одной таблице.
Нежелые (производственные ) в другой таблице. Но возникает вопрос переоборудования первых во вторые и на оборот. Добавлено @ 14:25
Это общее для всех зданий- если имееться ввиду из чего сделан дом, а не внутренняя отделка. Добавлено @ 14:27
Возможно покупка квартиры на первом этаже жилого дома и переоборудование в оффис а также и обратное действие. Это сообщение отредактировал(а) bas - 3.7.2006, 14:28 |
||||
|
|||||
| leniviy |
|
||||
|
Опытный Профиль Группа: Участник Сообщений: 552 Регистрация: 8.2.2003 Где: Спб Репутация: нет Всего: 5 |
Насчёт большого количества таблиц. Мне просто интересны возражения против этого. Если в каждой по 10 строк - это плохо, я понимаю. А если 100000? Добавлено @ 14:36
|
||||
|
|||||
| skyboy |
|
|||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
leniviy, не так важно количество. Я не знаю, о какой СУБД речь, но если вдруг к жилым/нежилым помещениям добавится ещё какая-нить категория, то при использования разных таблиц срочно понадобятся динамические запросы.. А оно - зачем? А выбор человека по адресу.... Если адрес записан в BLOB-поле, то одно время на поиск, если отдельно - улица, дом, квартира, то время совершенно другое!
да и потом: квартира как объект не зависит от того, снимает её человек для жилья, или фирма для магазина. Количество комнат не меняется. Не меняется площадь балкона и высота потолка. Потому, как на меня, не стОит дробить на отдельные таблицы. |
|||
|
||||
| leniviy |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 552 Регистрация: 8.2.2003 Где: Спб Репутация: нет Всего: 5 |
похоже придётся делать одну таблицу: гибкость в ущерб скорости
|
|||
|
||||
| bas |
|
||||
|
Опытный Профиль Группа: Участник Сообщений: 446 Регистрация: 14.8.2002 Где: Молдова, Кишинев Репутация: нет Всего: 2 |
Скорость определяеться оптимизациее (использованием индексов - естественных, сурогатных, кляйстерных, обычных .....).
Да не обязательно динамических. Но создание таблицы и настройка связей - 100%. При наличии справочника категорий помещений - достаточно добавить новую категорию и поехали дальше без переделки кода. |
||||
|
|||||
| beroal |
|
|||
 Бывалый Профиль Группа: Участник Сообщений: 212 Регистрация: 18.1.2003 Где: Украина Репутация: нет Всего: 3 |
А у вас собственно какая должность? Если младший программист, то лучше не настаивать на своём мнении...  Я думаю, это вопрос именно иерархический, а не идеологический. |
|||
|
||||
| LSD |
|
||||||||
 Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Поиск с использованием индекса, в таблице с 1 и 10 млн записей, по времени отличается весьма незначительно. Для этого индексы и создавались. Да и не такая уж это большая таблица (если СУБД не Paradox конечно).
Для этого есть триггеры.
Это вообще, не проблема БД, а проблема пользовательского интерфейса и влиять на архитектуру БД не должна.
Структура базы усложняется, больше вероятность ошибки. Например может потребоваться добавить столбец во все таблицы с помещениями, и одну забудут, что тогда? -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
||||||||
|
|||||||||
| chief39 |
|
|||
 карманная тигра Профиль Группа: Участник Клуба Сообщений: 1631 Регистрация: 20.5.2005 Где: Киев Репутация: 8 Всего: 77 |
Можно сделать вариант с базовой таблицей, в которой содержатся ОБЩИЕ данные, подходящие под ЛЮБОЙ учитываемый объект.
И таблицу под каждую категорию, связанную 1:1 с базовой. И держать в них данные специфические для каждого типа объекта. (А-ля "наследование таблиц"). Немного сложнее, но весьма логично представляет реальный мир, поэтому легче для НЕПРОТИВОРЕЧИВОГО ЛОГИЧНО ВЫВЕРЕННОГО расширения. Если добавится новый тип объектов - то просмотр базовых данных позволит с ним сразу работать. А специфику можно позже дописать. По крайней мере быстрее чем в случае одной универсальной таблицы и легче(в плане объёма работ), чем при отдельных таблицах. Это путь, по которому пошёл бы я. Необязательно лучший или даже хороший  Один из вариантов. А размеры таблиц вполне нормальны. -------------------- Люди - это свечи. Они либо горят, либо их - в жопу!(с) |
|||
|
||||
| Vit |
|
|||
 Vitaly Nevzorov Профиль Группа: Экс. модератор Сообщений: 10964 Регистрация: 25.3.2002 Где: Chicago Репутация: 14 Всего: 207 |
Пляшите не от производительности (миллион записей - это вообще-то не большое количество, нормальная база данных будет искать мгновенно) а от бизнес логики. Каждая таблица должна описывать одну и только одну сущность. В контексте вашей задачи все помещения представляют собой одну сущность или нет? Приведу пример: если для квартиры описывается количество комнат, ванн, балконов, паркет в комнатах, кафель в ванне, наличие евросантехники и т.п., а для производственных площадей описывается наличие трёхфазных розеток по 380 вольт, количество конференц-залов, наличие буфета в здании и проходной по пропускам - то имеются ввиду разные сущности, они имеют разные аттрибуты и разную логику оперирования, для них надо использовать разные запросы. Если же например любая недвижимость описывается только площадью, ценой и её типом - то сущность одна, никаких специальных операций над базой данных в зависимости от типа базы не предвидится. Есть правда одно исключение, если 99% операций одинаково, а сущности разные но похожие то можно их рассматривать как одну таблицу - будет удобнее работать. А если же сущности идентичные по свойствам, но все операции над ними абсолютно различны (т.е. несмотря на то что и жилые и нежелые помещения имеют абсолютно одинаковое описание, но практически в 99% случаев ни одна операция не оперирует сразу с разными типами) то имеет смысл иметь 2 таблицы.
-------------------- With the best wishes, Vit I have done so much with so little for so long that I am now qualified to do anything with nothing Самый большой Delphi FAQ на русском языке здесь: www.drkb.ru |
|||
|
||||
| leniviy |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 552 Регистрация: 8.2.2003 Где: Спб Репутация: нет Всего: 5 |
в 99 случаях из ста юзеру нужны только квартиры, но иногда ( очень редко ) надо посчитать все помещения в городе
|
|||
|
||||
| chief39 |
|
|||
|
карманная тигра Профиль Группа: Участник Клуба Сообщений: 1631 Регистрация: 20.5.2005 Где: Киев Репутация: 8 Всего: 77 |
Речь о том, одинаковые ли характеристики и атрибуты у различных помещений и нужна ли специфика для каких-либо типов... -------------------- Люди - это свечи. Они либо горят, либо их - в жопу!(с) |
|||
|
||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0614 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |