dev.net.ua

Поперше цікаво хто використовує моножину, а хто однину. Наприклад Мікрософт з цим визначитись неможе. Продививився бази данних TFS, так там навіть в межах однієї бази данних використовуть обидві схеми.

А ще префікси. Теж цікаво. На прикладі тогож самого TFS. Іноді використовуються іноді ні. До речі префікси теж бувають різні. Наприклад в TFS є префікси tbl_ - хм.. тобто.. ну добре незрозуміло, певне щоб неспутати таблиці з в'юхами? А бувають коли частини розіляють, а буває що префікс означає систему, це певне для того щоб потім можна було інтегрувати в одну базу данних?

---

MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)

Я роблю так:

• Таблиці без префіксу
• View з префіксом v
• Stored Procedures з префіксом usp_
• UDF з префіксом udf_
• FOREIGN Keys з префіксом FK_
• Індекси з префіксом IDX_
• CHECKs з префіксом CHK_

Якщо в майбутньому знадобиться створювати, ще якісь обїекти рівня таблиці, то префікс великими літерами, а якщо рівня схеми то маленькими. Довжина префіксу не більше ніж 3 символи, формат <літери>_, єдине виключення, це View.
Розділення на підсистеми за схемами. Найкращий приклад, це база AdvetureWorks с прикладів SQL Server 2005.

PS. Не можливо який саме засіб іменування ви використовуете, важливо, щоб в він був і всі його дотримувалися.

Mike Chaliy:

А ще префікси.

Привет! По поводу префиксов к таблицам и вью - вопрос очень сложный. Если система большая с долгим предпологаемым временем эксплуатации, то очень вероятно что некоторые таблицы станут вью. А именовать вью как tbl_ хм, что то в этом от лукавого. видел не раз таких фриков.

 

Поэтому если заказчик хочет я префиксую табицы tbl_ а вью - uvw_ если не хочет - именую без префиксов. Можно было бы и функции и вью префиксовать как dat_ но это имхо занадто.

Функции и процедуры - наиболее удобная схема, имхо для функций ufn_ИмяТаблицы_ИмяОперации для процедуры usp_ИмяТаблицы_ИмяОперации. В такой схеме есть следующие удобства

1. имена сортируются автоматом по именам таблиц, а затем по операциям. В случае отсутствия нижней черты может возникнуть интерференция, неоднократно убеждались, что с чертой удобнее.

2. наличие префикса не дает запутаться в именовании.

3. ну и известная вещч про то что нельзя спшки именовать как sp_ приводит к длинне префикса в 3 символа и некрасивостям в случае с функциями и вью без символа u, это если вьюхи таки префиксуются.

 

 

ИМХО, имеет смысл использовать 2 шаблона именования для двух групп объектов:

- объекты уровня БД (таблицы, вьюшки, хранимки)

- объекты уровня отдельной таблицы (индексы, констрейнты, триггеры)

Для первых - использовать в качестве префикса код модуля / подсистемы / компонента (я думаю, понятно). Никаких tbl_%, v_%, usp_% и пр.

Для вторых - использовать в качестве префикса тип объекта (I_%, PK_%, FK_%, CHK_%, TRG_%).

 

Почему ? Все просто ;-)

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

таблицы - просто название, Stored Procedures - SP_ , View - vw_

а вообще если развить тему то я делаю под каждую сущность класс и таблицу с именем класса. Поля таблицы соответствуют свойствам класса. Класс имеет 3 метода - добавить, удалить, изменить, которые вызывают соответствующую SP. Также один метод возвращает объект класса по id из таблицы и один метод возвращает коллекцию классов (все записи из таблицы). Это базовый набор :)

Oleg Shastitko:

таблицы - просто название, Stored Procedures - SP_ , View - vw_

Использовать префикс sp_ плохая идея с точки зрения производительности http://dev.net.ua/blogs/kosinsky/archive/2006/12/26/1563.aspx

Oleg Shastitko:

а вообще если развить тему то я делаю под каждую сущность класс и таблицу с именем класса.

Для этого следует обратить внимание на специализированные object-relation mappers , кодогенераторы или даже ООСУБД.

Oleg Shastitko:

таблицы - просто название, Stored Procedures - SP_ , View - vw_

 

Называть SP именем начинающимся с SP в MSSQL просто нельзя, так как такое название зарезервированно системой и обрабатывается по несколько другим правилам.

А вьюшки отделять от таблиц хоть и можно, но это опасно с точки зрения развития проекта в будущем. Со временем вьюшки могут стать материализованными, т.е. перестать быть вьюшками. А таблицы стать вьюшками, и оставить за собой табличные имена - в результате в проекте будет зоопарк из найминг конвеншион.

 

Зрозуміло..., схоже єдиного бачення нема. Невже немає якихось Naming Guidlines?

Ось ще тут можна подивитсь на тему про однину та множину. Дуже цікаво.

Тепер моя осбоиста думка.

Я завжди використовую множину для таблиць. Ніколи не використовую префікси. В поточному проекті пробую використоуввати схеми.

Висловлю думку про те чому я використовую множину.

SELECT Somethig FROM Users - тобто ми вибираємо інформацію зі списка, а тому логічно(принаймні для мене) використання множини. Дотогож виходить природнє речення, чого не скажеш коли використовуєш однину.

Тепер про префікси.

Реально якщо в'юха просто відображає талицію то певне їй потрібен якийсь префікс, але швидше за все вона якось трансформує данні, тому певне в неї ім'я повинно відрізнятися. І якщо вибрати хрозуміле ім'я, то необхіжність в префіксах зникає.

---

MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)

shuklin:

Для этого следует обратить внимание на специализированные object-relation mappers , кодогенераторы или даже ООСУБД.

дык, а у меня свой кодогенератор :)

 

shuklin:

Называть SP именем начинающимся с SP в MSSQL просто нельзя, так как такое название зарезервированно системой и обрабатывается по несколько другим правилам.

хм, надо будет пересмотреть, хотя проблем никогда не было

 

shuklin:

А вьюшки отделять от таблиц хоть и можно, но это опасно с точки зрения развития проекта в будущем. Со временем вьюшки могут стать материализованными, т.е. перестать быть вьюшками. А таблицы стать вьюшками, и оставить за собой табличные имена - в результате в проекте будет зоопарк из найминг конвеншион.

ни разу такого не было...

Oleg Shastitko:

ни разу такого не было...

Или везет ))) или проекты не столь сложны.

Мне постоянно попадаются уродцы, в которых tbl_ это уже вью а vw_ это уже таблица. Ну это обычно там не самое страшное, самое страшное это зоопарк VB6 + VBS + VB.NET + C# + MTS + DCOM + Remoting ...

shuklin:

А вьюшки отделять от таблиц хоть и можно, но это опасно с точки зрения развития проекта в будущем. Со временем вьюшки могут стать материализованными, т.е. перестать быть вьюшками. А таблицы стать вьюшками, и оставить за собой табличные имена - в результате в проекте будет зоопарк из найминг конвеншион.

Не совсем согласен. Мы придерживаемся подхода, что доступ к данным только через View & SP. То есть даже если мне нужен запрос из таблицы MyTable, то я опсиываю View, которая эту информацию содержит и называю ее vMyTable. В таком случае, таблицы это не что сравни приватным полям в классе, а вьюха похожа на Property.

А индексированость вью, это особеность физической оптмизации, решение о которой может принять DBA уже на живом проекте. 

А обращение к табицам внутри SP а внутри самих VIEW ? Просто проблему немного дальше закопали и все. Вобщем для меня этот вопрос спорный как таблицы и вью именовать.

shuklin:

А обращение к табицам внутри SP а внутри самих VIEW ? Просто проблему немного дальше закопали и все. Вобщем для меня этот вопрос спорный как таблицы и вью именовать.

Я соглашусь, что тут выработать действительно нормальный подход достаточно сложно? т.к.:

• иногда в дело включаеться его величество оптимизатор (особенно в SQL Server 2000)
• обновление View не самый лучший вариант с точки зреня производительности
• есть еще OwnerShip chains и реализуемая на его основе row-level security
• и все эти факторы могут влиять друг на друга.

По этому во внутренней реализации в каждом конкретном случае, я стараюсь выбирать оптимальный для этого случая вариант. 

 

я View использую только в случае объединения 2-х и более таблиц, иначе запрос делаю прямо к таблице. Соответственно, ситуация, когда View может стать таблицей, довольно редка...

Я думаю, первинна мета префіксів для декого - це виконання ролі угорської нотації... як на мене це не дуже correct, однак оскільки в SQL немає неймспейсів... найбільш зручне, що залишається, це користуватися префіксами. (Особисто я не користуюсь)

---

Everything should be made as simple as possible, but not simpler (с) Albert Einstein