На мой взгляд это классическая схема отношений сотрудник - отдел - руководитель Поэтому - во первых необходимо нормализовать БД - сделать отдельную сущность для сотрудников (руководитель то же сотрудник!), отдельную сущность для отделов и в зависимости от бизнес-требований построить отношение между сотрудником и отделом либо как многие-ко-многим (так очень часто делают), либо если организация небольшая, то один ко многим.
Дальше уже сильно зависит от бизнес-процессов в компании.
Трындец - вместо схемы "выключаем, включаем... через экран.... штекер"
Предложение: Приложить схему, описать ожидаемое поведение "включил выключатьель К1, появилось питание на разъеме Р1" и реальное "Включил К1, пошел волшебный дым из микросхемы U1. Почему?"
Валентин, Вики: Ба́за да́нных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) .
Про длительность хранения ни слова :)
Наверно опять попутана СУБД и БД :)
tukreb, Такое разделение которое у вас описано в вопросе, не встречал. Необходимость отделения части таблиц и отношений в другую БД встречал только при декомпозиции монолита на микросервисы. А вот обратный процесс - усложнение модели по мере роста бизнес-требований сплошь и рядом.
Что бы ответить на вопрос "как лучше разделить БД", необходимо понять "зачем"? Т.к. целей разделения в вопросе нет, как впрочем и ограничений, то ответ "как хотите". :)
Так, что желательно понять зачем нужно разделять БД?
P.S. Кстати модель БД довольно простая, и с этой стороны необходимости в разделении не вижу.
Ага, т.е. вам надо разделить одну модель БД на несколько БД.
Тогда необходимо подумать об обеспечении целостности данных. Как-то надо будет обеспечить связи между БД, либо на уровне БД, либо на уровне Application. Либо вообще забить на это дело.
Если есть ограничение на размер БД, то да, надо что-то думать.
А если нет, то Вы же не руками будете создавать эти 1000 записей я надеюсь, а слоем бизнес-логики.
Вывод всех RAM на складе со всеми атрибутами:
select *
from waterhouse
inner join Parts on waterhouse.idParts = Parts.idParts
inner join PartProperty on PartProperty.idPartPropery = Parts.idPartPropery
where Parts.idParttype = idRAM
А все зависит от железа: если один процессор, то поток будет всегда выполнятся один в один квант времени, а если у вас сто процессоров, то при хорошем раскладе 100 потоков в один квант времени.
Судя по количеству записей скорее всего смешана задача логирования и текущего состояния операции. Возможно имеет смысл разделить на разные сущности в соответствии с бизнес-логикой.
Дальше уже сильно зависит от бизнес-процессов в компании.