Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Например, table institute — запись об институте, название, адрес, реквизиты и т.д. PD>Поскольку речь идет о БД данного института, запись должна быть одна и только одна.
PD>А в нем факультеты, значит table faculty с FK на institute. Ну и прочие таблицы — бухгалтерия, отдел кадров и т.д.
А вы уверены, что вам нужны отдельные таблицы?
То что вы описываете, это оргструкрура.
Вуз -> Подразделение -> Дочернее подразделение ... -> что-то
Это все ложится в одну таблицу, просто со ссылкой на parent и типом строки.
Здравствуйте, BVA, Вы писали:
PD>>А в нем факультеты, значит table faculty с FK на institute. Ну и прочие таблицы — бухгалтерия, отдел кадров и т.д. BVA>А вы уверены, что вам нужны отдельные таблицы? BVA>То что вы описываете, это оргструкрура. BVA>Вуз -> Подразделение -> Дочернее подразделение ... -> что-то BVA>Это все ложится в одну таблицу, просто со ссылкой на parent и типом строки.
Как я понимаю, верхняя строчка этой иерархии (вуз) имеет особый тип с особыми атрибутами. И их надо где-то как-то хранить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
PD>>А в нем факультеты, значит table faculty с FK на institute. Ну и прочие таблицы — бухгалтерия, отдел кадров и т.д.
BVA>А вы уверены, что вам нужны отдельные таблицы? BVA>То что вы описываете, это оргструкрура. BVA>Вуз -> Подразделение -> Дочернее подразделение ... -> что-то BVA>Это все ложится в одну таблицу, просто со ссылкой на parent и типом строки.
Не понял.
У вуза десяток, а то и больше полей — название, адрес, реквизиты и пр.
У факультета несколько полей — название, корпус и т.д.
У группы полей немного — название скорее всего, и только.
У отдела кадров свои поля, у бухгалтерии свои
Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?
Здравствуйте, Pavel Dvorkin, Вы писали:
BVA>>Это все ложится в одну таблицу, просто со ссылкой на parent и типом строки. PD>Не понял. PD>У вуза десяток, а то и больше полей — название, адрес, реквизиты и пр. PD>У факультета несколько полей — название, корпус и т.д. PD>У группы полей немного — название скорее всего, и только. PD>У отдела кадров свои поля, у бухгалтерии свои PD>Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?
По идее это можно моделировать немного иначе. Одна таблица — хранит собственно иерархию, оргструктуру — какие подразделения организации кому подчиняются.
Другие таблицы хранят разные вещи о чём-то. Например, таблица адресов + таблица связей "поразделение -> адрес". То же с таблицей реквизитов и т.п.
У вас маленький ВУЗ, наверное, и имеет один адрес, несколько стоящих рядом зданий. А большие ВУЗы могут быть географически распределённые. Например, в университете может быть куча факультетов и ещё пара дочерних институтов со своими факультетами, в разных концах города, со своей бухгалтерией и реквизитами, да ещё филиал в другом городе.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, BVA, Вы писали:
PD>>>А в нем факультеты, значит table faculty с FK на institute. Ну и прочие таблицы — бухгалтерия, отдел кадров и т.д.
BVA>>А вы уверены, что вам нужны отдельные таблицы? BVA>>То что вы описываете, это оргструкрура. BVA>>Вуз -> Подразделение -> Дочернее подразделение ... -> что-то BVA>>Это все ложится в одну таблицу, просто со ссылкой на parent и типом строки.
PD>Не понял. PD>У вуза десяток, а то и больше полей — название, адрес, реквизиты и пр. PD>У факультета несколько полей — название, корпус и т.д. PD>У группы полей немного — название скорее всего, и только. PD>У отдела кадров свои поля, у бухгалтерии свои
PD>Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?
Попробуйте написать список полей для каждой сущности, потом проверьте, на сколько они нормализованы и на сколько совпадают. Из того, что описали не совсем понятно в чем проблема.
После нормализации, таблица иерархии у вас точно будет содержать id, название, тип, id родителя, id руководителя/старосты, возможно что-то еще общее для всех уровней.
Адрес это обычно отдельная сущность (и он будет на каждом уровне иерархии, что бы например у той же бухгалтерии была возможность переехать в отдельное здание).
Реквизиты вуза — пока не понятно, что это. Если это лицензия — то скорее всего это будет тоже отдельная таблица в которой будут все лицензии полученные вузом.
По поиску — тоже нужно понять, какие сценарии использования подразумевают поиск?
Да, еще стоит погуглить по словам
Table-Per-Type
Table-Per-Concrete
Table-Per-Hierarchy
Здравствуйте, BVA, Вы писали:
PD>>Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?
BVA>Попробуйте написать список полей для каждой сущности, потом проверьте, на сколько они нормализованы и на сколько совпадают. Из того, что описали не совсем понятно в чем проблема.
Ну пусть только те, что я в предыдущем сообщении написал. Задача учебная, сойдет.
Уточняю.
У вуза название, адрес, и 3 независимых друг от друга реквизита
У факультета название, корпус.
У группы название (старосту не буду, чтобы не заводить таблицу студентов)
Ну и всем Id, конечно.
Вполне нормализовано
BVA>Да, еще стоит погуглить по словам BVA>Table-Per-Type BVA>Table-Per-Concrete BVA>Table-Per-Hierarchy
Известно давным-давно.
В общем, ты предлагаешь Table-Per-Hierarchy с дискриминатором, видимо. Нет, не нравится мне эта идея, как и вообще этот подход. Свалить все в одну кучу — не лучшее решение.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, BVA, Вы писали:
PD>>>Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?
BVA>>Попробуйте написать список полей для каждой сущности, потом проверьте, на сколько они нормализованы и на сколько совпадают. Из того, что описали не совсем понятно в чем проблема.
PD>Ну пусть только те, что я в предыдущем сообщении написал. Задача учебная, сойдет.
BVA>>Да, еще стоит погуглить по словам BVA>>Table-Per-Type BVA>>Table-Per-Concrete BVA>>Table-Per-Hierarchy
PD>Известно давным-давно.
PD>В общем, ты предлагаешь Table-Per-Hierarchy с дискриминатором, видимо. Нет, не нравится мне эта идея, как и вообще этот подход. Свалить все в одну кучу — не лучшее решение.
Ну если задача учебная и все ограничивается 4-мя сущностями, то любой вариант подойдет. Лучше тогда твоего преподавателя спросить, какая из этих бест практик является лучшей по его мнению. Оценка от этого зависеть будет.
В реальном вузе просто иерархии могут быть достаточно сложными и с разной глубиной. например та же группа может быть на 1-2 курсе в прямом подчинении у факультета, на 3 и выше у кафедры. В обеспечивающих подразделениях вообще может быть бардак. Тех же отделов кадров бывает несколько в разных участках иерархии.
Здравствуйте, BVA, Вы писали:
BVA>Ну если задача учебная и все ограничивается 4-мя сущностями, то любой вариант подойдет. Лучше тогда твоего преподавателя спросить, какая из этих бест практик является лучшей по его мнению. Оценка от этого зависеть будет.
Я и есть этот самый преподаватель и хотел узнать мнение сообщества, как это лучше сделать, что рекомендовать учащимся.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не понял. PD>У вуза десяток, а то и больше полей — название, адрес, реквизиты и пр. PD>У факультета несколько полей — название, корпус и т.д. PD>У группы полей немного — название скорее всего, и только. PD>У отдела кадров свои поля, у бухгалтерии свои
PD>Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?
Данных выглядит как с гулькин нос. положите все в git и грепайте его. плюс, будет история изменений за бесплатно.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я и есть этот самый преподаватель и хотел узнать мнение сообщества, как это лучше сделать, что рекомендовать учащимся.
Как преподаватель ты должен рассказать и показать разные подходы, проанализировать достоинства и недостатки каждого, сформировать критерии выбора подхода в зависимости от ситуации. Догматично указать один, как-то не комильфо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Есть ли какая-то best practice для такого случая :
Тут кучу вариантов предложили решения уже.
Я так понимаю, это учебная какая-то абстрактная задача.
Для нее в принципе не может быть абстрактного лучшего решения.
И мне кажется что цель обучения это показать плюсы и минусы разных вариантов (в том числе из предложенных) в зависимости от конкретных требований.
Я например как человек разрабатывающий в основном low latency сервисы имею предубеждение против экстремальной нормализации ведущей потом к бессмысленным joins с таблицей с одной записью.
Это потеря каких то миллисекунд или пусть даже долей миллисекунд но абсолютно на пустом месте.
Там где критерии оптимизации другие, можно сделать хоть одну запись с check constraint, хоть запись с константным magic id (еще проще).
Там где в будущем возможно расширение как количества институтов так и количества полей, могут быть какие-то другие варианты решения и т.п.
В обучении нужно меньше догматизма и больше диалектики
Здравствуйте, TK, Вы писали:
PD>>Какой строки ? Все поля для каждого типа в одну строку упаковать ? А поиск потом как вести ?
TK>Данных выглядит как с гулькин нос. положите все в git и грепайте его. плюс, будет история изменений за бесплатно.
Ты не понял, о чем речь идет. Задача для учащихся — создать РБД, и вот один вопрос тут возник о ней. А не о поиске вообще.
Здравствуйте, ·, Вы писали:
PD>>Я и есть этот самый преподаватель и хотел узнать мнение сообщества, как это лучше сделать, что рекомендовать учащимся. ·>Как преподаватель ты должен рассказать и показать разные подходы, проанализировать достоинства и недостатки каждого, сформировать критерии выбора подхода в зависимости от ситуации. Догматично указать один, как-то не комильфо.
Все верно. Но раньше или позже придется перейти к реализации, и вот тут я должен порекомендовать им один из подходов. Вот я и спросил мнения сообщества, какой они считают наилучшим.
Здравствуйте, Pavel Dvorkin, Вы писали:
TK>>Данных выглядит как с гулькин нос. положите все в git и грепайте его. плюс, будет история изменений за бесплатно. PD>Ты не понял, о чем речь идет. Задача для учащихся — создать РБД, и вот один вопрос тут возник о ней. А не о поиске вообще.
Тут вопрос в другом. Есть вообще уверенность, что РБД тут правильный инструмент? Понятно, что его можно натянуть его на любой глобус, но зачем и чему это научит?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Тут вопрос в другом. Есть вообще уверенность, что РБД тут правильный инструмент? Понятно, что его можно натянуть его на любой глобус, но зачем и чему это научит?
