Какой подход к проектированию базы данных выбрать?
Есть список организаций. У организации есть имущество (жилое, нежилое, недвижимое, движимое, здания, земельные участки), у организации есть люди, проживающие в комнатах помещений, в квартирах на земельных участках.
У организации есть нарушения. Например, если проживает много людей в одном помещении.
Еще у организации есть различные документы, характеризующие ее имущество, людей-сотрудников и прочее-прочее-прочее.
Изначально не известно, какие возможные свойства организации могут быть и по каким критериям нужно выводить данные. Например, нужно всегда знать, сколько сотрудников в организации. Но при этом сотрудники работают в помещениях, а еще сотрудники могут получать награды и призы. Они могут увольняться. Они могут иметь ФИО, а могут быть просто "сотрудник №2938, неизвестный".
Организаций 1000. Совокупное количество разных сущностей (машин, домов, людей, нарушений) может переваливать, наверное, за миллиард. Но на самом начале будет немного. Забивка подобной базы может быть годами. И она должна будет выдержать расширение по сущностям, по их количеству.
У каждых данных есть актуальность. Нужна история.
Как проектировать подобную БД? Выбирать объектный подход, подход фактов и измерений?
Пока в голову пришел объектный подход. Где присутствует наследуемость, определенные типы связей, возможность превращения свойства в объект (например, когда у Дома есть поле "кол-во лифтов", а затем необходимо будет превращать свойство "кол-во лифтов" в привязанные к Дому объекты "Лифт", которых будет N штук, каждый из которых со своими параметрами (высота, нагрузка, год ремонта). А так же, изначально статистика по Лифтам могла и не собираться. Потом стали собирать. Но при этом добавления новой сущности "Лифт" (или для начала своства "лифт" у Домов), должно происходить автоматически, по нажатию кнопочки в UI, равно как и создание связей и представлений.
На этом примере с домами и лифтами показываю, что а) база может изменяться, и б) количество сущностей и их свойств, а так же связей неизвестно и расширеямо, как по качественному признаку, так и по количественному.
С одной стороны задача простая, а с другой стороны, находится столько нюансов, и проблем с производительностью, что голова кругом идет.
То, что голова идет кругом - вернейший признак того, что нет бизнес-требований. В идеале, за такую базу не нужно браться вообще - это прямой путь к увольнению. "Вот нам надо было, а Павел сделал все не так, а нам надо было так!"
Ну и попытка объять необъятное тут. Мега-учет в одно лицо? Не надейтесь справиться, никто это в одиночку не делает. Вот это все "количество сотрудников в комнате", "количество лифтов" - крайне сомнительно, что это вообще нужная информация.
Мои рекомендации: сесть и спокойно подумать о чем-то другом. Пару дней. Понять реальные требования в их минимальном масштабе. Конкретизировать их. Не спешите думать о структуре.
Нужен учет сотрудников в организации - это уже отдельная база данных. Нужен учет материальных средства - это еще одна отдельная база данных. И так далее.
И заметьте - на рынке есть решения этих вопросов, но нет монополиста и есть масса самописных решений. Это о чем говорит? Еще раз о том, что универсального решения нет, но есть методы для _конкретных_ задач.
Требований нет. Есть проблема-задача о мониторинге различных параметров организаций. Критерии могут быть какими угодно, под каждое желание ревизора писать свой запрос - никаких сил не хватит. Павел тут не один, Павел тут просто вопросы задает =)
Мы тут сидим, думаем над этой задачей. Мозговой штурм привел нас вот к той реализации к объектам, сущностям и свойствам.
Универсального решения подо все понятное дело нет, но есть же практики ORM, OLAP. Они же решают какие-то очень конкретные задачи достаточно общим подходом. Вон, раньше, не было MVC-фреймворков, но появились же. Причем довольно стремительно за последние пару-тройку лет.
Вот поэтому и задаю вопрос, может быть кто что посоветует из собственного опыта.
Спасибо за ваш развернутый комментарий)
Больше похоже на оффтоп, но:
Судя по вашему описанию https://www.palantir.com/ ценник которого с множеством нулей
А данные для него в любом электронном виде.
А если серьезно, то берем одну сущность, описываем, добавляем следующую, описываем ... и т.д.
Таблица Сотрудников
Простой
