guest_20040621Похоже, мир перевернулся: девушка вечером второго января задает вопрос о проектировании баз данных. Причем, "для себя"+1

SunnyGirl P.S. в некоторых таблицах я использовала суррогатный ключ ID там где он казалось бы и не нужен - привыкла работать с суррогатными ключами: удобнее при осуществлении Insert/update/delete where id=:id.Для таких таблиц типа свойства объекта Х я задаю составной первичный ключ типа xID, ID и стало быть DML будет where id=:id and xID=:xID.

SunnyGirl не уверена в своем подходе: общий справочних контрагентов с общими юр. данными и отдельные таблицы на каждый вид договора. (по логике (в большинстве случаев) в одном запросе будет участвовать только одна таблица договоров.)Недавно был топик про наследование на примере грузовых и легковых автомобилей с общими полями. Если есть требования уникальности(типа ИНН) или поиска(типа по имени) необходима таблица с общими полями.

SunnyGirl Интересует также правило наименования колонокТо есть что лучше префиксы или суффиксы. Поверьте, это проблема типа каким должен быть подоконник - вровень со стенкой или выпирать. Лишь бы он не вровень выпирал (с) Равшан.

SunnyGirl контроль доступа - 3х звенка- на уровне серверной логике, + все работы с данными через процедуры, где возможно реализация проверки ( но то что свой велосипед изобретать придется - в курсе: сейчас ограничение либо только смотреть/либо все)
Просто примите как факт что база данных будет использоватся не только вашей серверной логикой. программы приходят и уходят, а данные остаются.

SunnyGirl Осталось поразмыслить и придумать механизм ведения истории изменений (переносить в таблицу истории с удалением записи в основной или выставлять период действия данныхПридумывать ничего не надо, все уже придумано до вас. Если исторические данные нужны сравнительно редко то их лучше помещать в доп.таблицу с полями dfrom dto. Если к каждому запросу требуется дата (а тариф для абонента такого типа в этом году был ...) тогда поля dfrom dto добавляются в основную таблицу.

guest_20040621> Сегодня днем гляну 1С
Напрасно потратите время.Еще один взгляд на то как можно решать проблему лишним не будет. Другое дело что надо самостоятельно понять почему был выбран данный подход, какие у него достоинства/недостатки.

Рекомендую на первом этапе не пытаться предугадать что еще может поменятся, а просто реализовать "как есть".
Затем начать моделировать ситуацию - а что если у нас появится новый XXX или выйдет постановление о YYY или потребуется синхронизировать с ZZZ, какие изменения в базу данных и приложение придется вносить. А если и не появится, не выйдет, и не потребуется сколько будет стоить заранее реализовать такую возможность.
Еще один немаловажный фактор - простота . Начинающие любят хитрые гибкие навороченные решения.

guest_20040621Критерий качества любой структуры данных у меня один: сохранение возможности ее развития без радикальных измененийЯ для себя вывел другой критерий - баланс или гармония.
Некрасивые самолеты не летают (с) А. Туполев