|
2 Volodja: \r
\r
Надо создать базу обработки заказов. По ходу дела для таблицы заказов необходимо где-то около 40-50 полей. Особенность: к разным полям должны иметь разный доступ люди из разных подразделений(расчет, доставка, экономисты и пр.). Есть поля, которые должны видеть(обрабатывать) пользователи с разными привилегиями. Другие поля нужны только какому-то конкретному отделу.....\r
...\r
...Есть мысль разделить таблицу на несколько, т.к. вероятность того, что с такой длинной записью одновременно будут работать велика. Либо как-то можно делать блокировки на поле, а не на всю запись(как не знаю)? \r
\r
Собственно сама идея:\r
вынести т.е атрибуты(столбцы) сущностей(таблиц), к-рые будут изменяться одной группой пользователей в отдельные сущности. Установить идентифицирующие (т.е. внешний ключ в дочерней таблице является также и первичным) отношения 1:1 между сущностями. \r
\r
Причины? \r
1) Размер строки в MSSQL не может превышать ~8К, т.е возможно вам просто физически не удастся\r
запихнуть такое кол-во столбцов в одну таблицу, особенно если там есть длинные varchar.\r
2) Суммарный размер данных на 1 индекс в MSSQL не может превышать 900 байт, количество столбов\r
на 1 индекс <=16. (Хотя зависит конечно от того какие CRUD-запросы планируются и какие\r
композитные индексы под них понадобятся)\r
3) Возможное кол-во row (и возможно tab) блокировок уменьшится, т.к скорее всего столбцы\r
используются разными группами пользователей для разных CRUD операций. Серверу гораздо легче\r
будет обновлять индексную информацию. Также возможно уменьшится кол-во сортировок в страницах,\r
если будет использоваться кластерный индекс например.\r
4) MSSQL позволяет назначать права пользователям и на отдельные столбцы и группы в одной\r
и той же таблице, однако гораздо элегантнее назначать права группам сразу на таблицу целиком.\r
\r
...Техзадания как такового тоже.... \r
\r
ТЗ на БД как на подсистему приложения/ИС (далее - "систему") и ТЗ на саму систему очень желательно, я бы даже сказал - обязательно! Поскольку ТЗ - это не документ на 3 страницах и конечно требует затрат на создание, то кому и для чего он нужен?\r
\r
1. Разработчикам (исполнителям) . Собственно для Разработчиков ТЗ - это важный, центральный документ,\r
в к-рый каждый должен всегда заглядывать чтобы не отклоняться от т.н "генеральной линии" разработки\r
и дабы не заниматься самодеятельностью, к-рая может просто похоронить проект.\r
Вобщем поскольку ТЗ содержит как функциональные так и не функциональные требования на систему в кратком виде,\r
то ТЗ прекрасный документ для этих целей. Следующим архитектурно более подробным документом является\r
Технический проект (ТП).\r
\r
2. Заказчику . Собственно для Заказчика ТЗ - это важный документ (если конечно следовать\r
де-факто цивилизованным принципам создания систем и опять же стандратам вроде ГОСТ,ISO,SEI):\r
общая спецификация на основании к-рой система будет приниматься в эксплуатацию.\r
ТЗ как правило утверждается Заказчиком, но вы здесь про заказчика умалчиваете, так что... :)\r
\r
В силу свой специфичности БД как подсистемы, ТЗ на БД естественно отличается от ТЗ на всю систему.\r
Вот некоторые причины: ТЗ на систему как правило выдерживается в соответствии\r
с выбранным стандартом, например, ГОСТ 34.602 (в РФ) и это ТЗ показывается Заказчику, поэтому этот\r
документ следует определенным формальностям . ТЗ на БД не обязательно выдерживать в соответствии, поскольку: а) это ТЗ как правило редко показывается Заказчику (действительно ТЗ на систему\r
уже содержит общие спецификации на хранимые и обрабатываемые данные и подсистемы (СУБД и тд.)),\r
б) опять же если следовать тем же стандартам, например, 34.602, то он слишком общий\r
и все-таки более подходит для АС или ее подсистема, а БД слишком специфична,\r
в) такой "неформализм" действительно гораздо удобнее, тогда ТЗ на БД - финальный документ\r
и ТП на БД как бы не нужен.\r
(Хотя я знаю пару-тройку контор в к-рых ну очень педантичные и неленивые люди и они всегда делают\r
отдельно как ТЗ, так и ТП.)\r
Следует отметить, что я видел вобщем много различных вариантов ТЗ на БД, как наших, так и импортных,\r
и скажем сумел ИМХО достаточно рационально обобщить самое полезное именно для разработчиков.\r
Итак, ТЗ на БД что содержит этот документ, если в контексте всего вышесказанного?\r
\r
НЕФОРМАЛЬНОЕ ОПРЕДЕЛЕНИЕ: ТЗ - это документ-спецификация, содержащий все необходимое чтобы:\r
а) на основе него создать БД, удовлетворяющую всем заложенным в ТЗ однозначным требованиям;\r
б) на основе него принять эту БД в эксплуатацию, т.е. проверить что БД удовлетворяет требованиям; и\r
в) на основе него оттестировать эту БД, т.е. подтвердить некую достаточную работоспособность БД.\r
\r
СОДЕРЖИТ: (разделы для реляционной БД без OLAP)\r
\r
1. Описания бизнес-правил. \r
(- отношения между сущностями, целостность данных, описанные естественным языком)\r
2. Описания доменов. \r
(- понятно)\r
3. Описания сущностей (логическая модель). \r
(- желательный раздел, даже если есть п.3)\r
4. Описания таблиц (физическая модель). \r
(- относительно избыточный раздел, если есть п.4, нет п.7)\r
5. Описания запросов. \r
(- все запросы необходимые приложению и описанные естественным языком)\r
6. Описания правил безопасности. \r
(- списки групп/пользователей, права на операции, ACL для таблиц и других объектов)\r
7. Требования к производительности. \r
(- требования времени исполнения и ресурсам при выполнении запросов, максимально-допустимые нагрузки,\r
рекомендации по индексам)\r
8. Требования к тестовым данным и запросам. \r
(- тоже что и п.5, но упор делается на именно на "стрессовость" и обеспечение производительности)\r
\r
ПЕРВИЧНЫЕ ДОКУМЕНТЫ: \r
1. ТЗ на создание ИС/приложения.\r
2. Словарь терминов предметной области (если не входит в п.1 или в ТЗ на БД).\r
3. ......\r
\r
ПОЛУЧАЕМЫЕ АРТЕФАКТЫ: \r
1. Логическая модель данных.\r
2. Физическая модель данных\r
(3. БД или ее DDL-cкрипты.)\r
\r
ОСНОВНЫЕ ОСОБЕННОСТИ: \r
1. ТЗ на БД изменяется только в случае изменения основного ТЗ на систему или/и Словаря,\r
хотя допустимо что при анализе ТЗ на БД возникнут идеи, к-рые могут повлечть измения\r
обеих документов.\r
2. ТЗ на БД единственный документ определяющий структуру БД с необходимым\r
уровнем абстракции, ТЗ не должно содержать каких-либо ER-диаграмм, схем, SQL-кода\r
поскольку именно требования, описания и рекомендации к БД, выраженные естественным языком\r
как правило не меняются, а вот реализация (SQL, индексы, настройка СУБД/БД)\r
как правило меняется в процессе тестирования и оптимизации\r
\r
... Либо использовать представления? \r
\r
Возможности представлений/видов (обычных,индексированных,сегментированных) достаточно ограничены (все это описано в BOL) против тех же хранимых процедур(ХП) или функций. По собственному и чужому опыту знаю, что в реальной жизни им мало находится места. Возможно меня кто-то поправит. Как правило реальные БД - это таблицы, ограничения целостности, триггеры, индексы и ХП/функции\r
\r
Предполагается использовать MS SQLServer+Delphi. \r
\r
Если не секрет, то если кратко, чем обусловлен такой выбор? Выбор вполне стандартный (у нас тоже в 90%-MSSQL и в >60% проектов - Delphi), однако могут быть все же и другие варианты\r
\r
...Опыта проектирования баз нет. \r
\r
См. посты Работа: Оцените, плз, сколько это может стоить(+) (1,2,3), Работа: Перспективы свободных художников в Москве (1,2,3,4,5), обсуждение орг.вопросов, затрат,стоимости проекта - расширенный вариант поста Циничного Кота\r
\r
2 Циничный Кот: \r
Вариантов на вашем месте несколько: ...(и пошли, пошли коммерческие варианты!) \r
\r
Конечно правильные варианты, но может дать человеку самому поплавать? Глядишь и выяснится нужны ему такие варианты или нет, все-таки этот пока только БД+приложение, а не серьезная ИС типа самодельной CRM или MRP :)
|
