Правильная связь таблиц

Цитата Kitty @ 28.04.15, 07:35

2. Вставляю запись в таблицу rooms.

Если нет организации то и комнаты нет?
Если есть комната то и организация должна быть?
Может ли быть пустая комната, еще не занятая никем?
Организация есть, но комнаты для нее нет, или она еще только желает взять комнату но площадь ее не устраивает, или цена аренды высока - как вы ее зарегистрируете ?
Ответы на вопросы помогут, может быть.

Сообщение отредактировано: Bas - 28.04.15, 08:30

Понятно. Спасибо.

Цитата Akina @ 24.04.15, 06:17

У нас в одном здании сидит несколько организаций, имеющих один ИНН.

Могу ошибаться, но ИМХО, наиболее правильным будет уникальный ОГРН. Организации вправе именовать свои филиалы как вздумается, но в отчетности они будут фигурировать исключительно согласно гос.регистраци.

По поводу "индескации" номеров комнат - наиболее обобщенный вариант - VARCHAR. Многие используют "поэтажную" нумерацию, многие сквозную, многие вообще могут присвоить комнате номер "Щитовая №1", "Склад №2". И никому ниче не докажешь.

Цитата JoeUser @ 28.04.15, 15:23

ИМХО, наиболее правильным будет уникальный ОГРН.

Цитата JoeUser @ 28.04.15, 15:23

номеров комнат - наиболее обобщенный вариант - VARCHAR

Использование в качестве первичного индекса строковых типов, в общем, плохая идея. Как потому, что синтетический чисельный ключ более компактен, так и потому, что уникальность строк есть величина непостоянная, зависящая от charset и collation. Разумнее именно синтетический ключ и, если необходимо, UNIQUE KEY.
Случаи, когда натуральный ключ оправдан, на самом деле достаточно редки.

Цитата Akina @ 28.04.15, 15:30

Случаи, когда натуральный ключ оправдан, на самом деле достаточно редки.

Согласен. Я и написал - "обобщенный вариант". Просто когда у построителей тех.паспорта объекта "зашкаливает" - это чревато гемором у разработчика ПО.

Добавлено 28.04.15, 15:40
По поводу зданий, комнат, датчиков ... Просто имел и имею дело с одной относительно "уникальной" организацией - бизнесцентром. Напишу ряд "аксиом", чтобы было в памяти и на слуху...

1) У здания может быть только один владелец
2) Собственниками помещений в здании могут быть несколько организаций/юрлиц (выкуп)
3) Помещения могут быть собственностью, могут быть арендой
4) Датчики могут быть централизованными, могут быть собственностью
- помещение в собственности собственника1, датчики - собственность владельца здания
- помещение в собственности собственника1, датчики - собственность собственника1
- помещение в аренде арендатора1, датчики - собственность владельца здания
- помещение в аренде арендатора1, датчики - собственность арендатора1

Цитата JoeUser @ 28.04.15, 15:34

У здания может быть только один владелец

Да ладно... тебе что, незнаком термин "долевая собственность"? а если сюда ещё и доверительное управление приплести, совсем веселуха начнётся. Но все эти факты выпадают за пределы рассматриваемых в строящемся приложении бизнес-процессов.

Цитата Akina @ 28.04.15, 15:44

Да ладно... тебе что, незнаком термин "долевая собственность"?

Не не не - не путай. Собственниками в долях могут быть хоть триста организаций. Владельцем именно здания - одна. Как правило под это дело тупо создается юрлицо с уставными долями тех самых собственников. На 100% гарантировать не могу сказанное, три-четыре идентичных примера было в процессе работы.

Просто по логике - здание это неделимая сущность недвижимости (не путать с помещениями здания).

Спасибо за юридический ликбез, но ...... это автору не нужно, пока.

Сообщение отредактировано: Bas - 29.04.15, 06:04

Цитата Kitty @ 25.04.15, 19:12

По поводу схемы, я просто рисую на бумаге связи, мне надо приложить скан своего листочка?

Именно! И никаких скриптов пока на этих листочках не будет все гладко и стройно.

Добавлено 01.05.15, 09:03

Цитата Kitty @ 27.04.15, 09:06

Я не игнорирую. Буду добавлять. Просто хотелось услышать критику по поводу того, что самостоятельно сделала и насколько это неэффективно.

Игнорируете. И критиковать то нечего ибо нет основы.
Если не знаете с чего начать надо начинать по учебнику
1. Перечислить ВСЕ термины
2. Определить что есть сущности, что есть связи и что есть атрибуты связей
3. нарисовать ЕR модель
4. "Окончательно" определить атрибутику всех сущностей и связей.
5. Провести нормализацию
6. Сформулировать основные запросы и проверить что в полученной структуре "ответ" будет получен легко и ненавязчиво
7. Изучить предметную область и подумать что еще завтра захочет пользователь
8. по результатам 6 и 7 вернутся и повторить 1-5
9. Выбор СУБД
10. Написание скриптов

Вы же сразу кодируете. Это основная ошибка в проектировании БД.
Если есть желание можете числу к 10 подготовить по п. 1-8 и продолжим. Ибо до тех пор у меня забота где палатку ставить и куда завтра двигать