2 funikovyuri:
Я вообще против всяких венгерских нотаций и прочего - т.е. я считаю что имя должно иметь смысл в предметной области и НЕ обязано нести описание лежащего в его основе объекта (так считает например Голуб)

Если предметная область, то имя таблицы должно быть также в единственном числе , т.е как и сущности. Что касается венгерских, польских или прочих "заумных" нотаций, то главное, чтобы они удовлетворяли требованиям, см. пост выше (Дата: 30 сен, 00:16) да еще ссылка на "авторитет" наподобии того же Майкрософта или Борланда

Насчет insert vs add ... Я думаю право на существование более чем оправдано (тот же Мюллер предлагает даже в Use Cases применять SQL если это позволяет более эффективно выразить свою мысль) - такие имена понятны любому программисту на SQL

Названия UC должны быть прежде всего показывать "бизнес-цель" и быть понятны заинтересованным лицам (stakeholders), т.е пользователям и заказчикам ИС/ПО:

RUP Doc:
The following people will use the use cases:

Customers will use the use cases to understand the system's behavior,
and, since they must approve the use case's flow of events, customer will also
use the use cases to approve the result of use-case modeling.

Potential users will use the use case to understand the system's behavior.

Software Architects will use the use cases to identify architecturally
significant functionality.

...

Name
Each use case should have a name that indicates what is achieved by its interaction
with the actor(s). The name may have to be several words to be understood. ....


What Makes a Good Use-Case Name?
Dr. Use Case (aka Leslee Probasco)
...Except for a few critical use cases that are outlined by the end of the Inception
phase, the only information available about the identified actors and use cases are
their names . Along with specified features and other system requirements,
this must be sufficient for all stakeholders to have a clear enough understanding
of the functionality of the system in order to make this critical "thumbs-up" or
"thumbs-down" decision.
...
A basic rule-of-thumb I like to follow in naming use cases is that anyone (at least
anyone familiar with the problem domain) should be able to look at a use-case diagram
-- noting the actor and use case names, and their associations - and have a pretty
good idea of the value or goal to be achieved by each use case.
...
In the Guidelines for Use Cases, the RUP states that "each use case should have
a name that indicates what value (or goal) is achieved by the actor's interaction
with the system" ....

Странно, что Мюллер забыл об этом. Надо будет еще раз внимательно полистать его книгу. Зря я ее рекомендовал, если в ней необоснованно (а может там разработчики являются заказчиками/пользователями будущей системы?) нарушается методология в угоду разработчикам, к-рым "более понятен" SQL. Хотя у Мюллера, конечно, примеров больше, чем у Нейбурга & Максимчука


2 aag:
Обращаю внимание, что я писал о именно о Transact-SQL. Ни один из приведенных вами источников к нему не имеет отношения. А то, что для MFC есть подробные naming convention, это мне и так давно известно.

Да, но Naming Conventions for Microsoft Access (Backgrounders, May 25, 1994) имеет отношение к Jet-SQL и именованию объектов в Access:

If you've ever inherited a project from another developer, you know how frustrating
it is to try to dissect another developer's style and maintain his or her code.
When developers code with a common style, however, you can minimize these frustrations.
To best share ideas and knowledge, the Access development community will benefit greatly
if it adopts a common programming style so that we can benefit from each other's expertise
with a minimum of translation overhead.
....
Some elements of Hungarian style are used in Microsoft's Visual Basic manuals and
Development Kit documentation, among others. Microsoft uses Hungarian internally,
and many programmers around the world use it as well. We've adapted the Hungarian
style for the Access environment.

In our Access naming style, an object name is made up of four parts: one or more
prefixes, a tag, a base name, and a qualifier. The four parts are assembled as follows:

[prefixes]tag[Basename][Qualifier]



Не одинаково - единообразно, в одном стиле. Если же причины, то они должны быть очень весомыми. Кстати, вы их не привели. Когда приходится разбиратся с чужим кодом, другой стиль именования, форматирования и пр. очень затрудняет.

Спасибо, что поправил. Я это и имел в виду, но почему-то хорошее слово "единообразность" вылетело из головы.
Что касается причин - так меня не просили их приводить. Поэтому привожу:

необязательно, чтобы сущности/таблицы и классы именовались
единообразно , т.к
а) не во всех CASE-средствах есть раздельное моделирование OO и ER объектов,
а именно в CASE-средствах, использующих только UML как для OO, так и для ER
(например, в Rose, Visual UML, TauG2) даже в ER-модели сущности/таблицы являются
"классами" (class model element) со стереотипом <<entity>>/<<table>>.
б) во всех CASE-средствах наличие префиксов, указывающих на тип объекта
опять же повышает удобство работы и наглядность имен объектов, например, при
просмотре результатов поиска, когда запрос вида: "t_Order*" вернет
все объекты-таблицы из модели/пакета, а "*Order*" - все объекты,
в имени к-рых содержится просто "Order".


необязательно, чтобы ХП/триггеры и методы именовались единообразно ,
т.к см.выше;


необязательно, чтобы классы , методы , интерфейсы и т.д в разных
средах разработки/языках именовались единообразно , т.к если разработка ведется:
а) с использованием 2-х и более сред/языков в одной организации, то все равно
используется общая проектная документация (ТЭ, ТП и т.д), общий проект, содержащий,
например, как классы VB, так и классы Java. Поэтом наличие префиксов, указывающих на
среду/язык разработки объекта опять же повышает удобство работы и наглядность
имен объектов, например, при просмотре результатов поиска, когда запрос вида:
"clsOrder*" вернет все классы VB, а "JOrder*" - все классы Java, имеющие отношение
к заказам;
б) с использованием 2-х и более сред/языков с привлечением 2-х организаций
(такое тоже случается нередко), то в разных организациях - разные правила
именования или префиксы, а предложение другой организации "своих" правил чревато
даже если другая организация является субподрядчиком

Это мысль. Для некоторых исходников было бы полезно :)

No comments ;о)

На самом деле, я имел в виду, что если в некоторой базе все таблицы были названы "неправильно" (с вашей т.з.) во множетвенном числе, то добавление новых с "правильным" именованием будет еще большей ошибкой.

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

Эээ... Хотя у меня есть свои правила, но они противоречат тому бардаку который уже существует у нас. В силу вышеупомянутых причин они недоработаны.

Что ж рассмотрим нек-рые существенные отличия от того, что было выше с практической т.з:


Таблицы : t<м.б. Префикс подсистемы из 2-5 знаков>Orders
- если используются CASE-средства, к-рые позоволяют группировать ХП в пакеты
и работать с пакетами, то префикс подсистемы ничего не дает на стадии проектирования;
но он помогает при работе СУБД, не поддерживающей пакеты или пространства имен, например,
MSSQL, т.е в EM по имени таблицы можно понять, какой подсистеме она принадлежит.


PK,FK : PK_tOrders, FK_tOders_tCustomers
- т.е в именах ограничений табличный префикс "t" сохраняется, а в ХП и триггерах
почему-то нет.


Триггеры : OnInsertUpdate_Orders
- т.е просто префикс "On" является эквивалентом "tg_". При просмотре списка
имен триггеров в EM они не сортируются по таблицам или в запросе понадобится
..WHERE table = ...tOrders, чтобы увидеть триггеры для tOrders

... Напоследок хочу заметить, что в каком числе бы вы не указывали сущность, ни производительность, ни надежность базы данных от этого не изменится. И я сильно сомневаюсь, что сокращение наименований на буквочку "s" поможет сильно ускорить разработку :)

Ну, слава богу, что ты знаешь, что на производительность или надежность окончание "s" в именах не повлияет. Что же касается разработки, то сильно не сильно, но ускорит. По крайней мере не надо будет мозг и руки "напрягать" по поводу того же "ies" при написании, например, того же SQL кода. Так что копейка рубль бережет, а доллар штуку баксов :о)


2 папа Карло:
прослеживалась эгоистическая нотка... типа вот есть кимбал и есть все остальные... имеет право так говорить, но надо быть скромнее. как известно большой шкаф громче падает :)

Mr.Karlo is cool and doesn't buy that shit! Вот на что и дана своя соображаловка, чтобы отличить реальные знания, опыт и интеллект от самохвальства и использования авторитета :о)

2 funikovyuri:
В защиту Мюллера - UC - разные бывают (например описывается подсистема или просто вариант использования "ниже уровня моря")- и он имел в виду ситуацию когда SQL будет понятен все заинтересованным лицам и к тому же более лаконичен

Когда подобное имя/название ВИ (UC), содержащее термины SQL, понятно заинтересованным лицам, то тогда это конечно же допустимо. Что же касается подфункций/функциональных ВИ (subfunction use case), к-рые содержат описание достижения частичных или вспомогательных целей действующих лиц, то к их именам точно такие же требования как и к именам пользовательские ВИ (user-goal use case), к-рые содержат описание достижения конечных целей действующих лиц, т.к подфункции - это по сути такие же ВИ

25. APPENDIX C: GLOSSARY (стр.246)
("Writing Effective Use-Cases" ( * * P RE-PU B . D R AFT # 3 * *, date: 2000.02.21)

SUBFUNCTION USE CASE
A "subfunction use case" is one satisfying a partial goal of a user-goal
use case or of another subfunction. Steps are lower-level subfunctions.
Subfunction use cases support the user-goal use cases. They are only needed
only are called from several by other use cases or isolate a complicated
piece of behavior.

Я этот пример привел для того чтобы продемонстрировать что если что-то очевидно для разработчиков - это надо использовать (т.е. если все интуитивно знают что будет делать insert - то, почему бы его не использовать)

Еще раз: insert, delete и update можно использовать не тогда, когда они понятны разработчикам, а когда они понятны всем заинтересованным лицам. Заинтересованные лица и разработчики - это не одно и тоже. Разработчики являются подмножеством категории заинтересовнных лиц (множества проектных ролей RUP)

RUP Doc:
Role: Stakeholder
The stakeholder role is defined as anyone who is materially affected by the outcome
of the project. ..... Many stakeholders are users of the system. Other stakeholders
are only indirect users of the system or are affected only by the business outcomes
that the system influences. ....

Examples of stakeholders:
Customer or customer representative

User or user representative

Investor

Shareholder

Production manager

Buyer

Designer

Tester

Documentation writer

and so on

stakeholder need
The business or operational problem (opportunity) that must be fulfilled in order
to justify purchase or use.

Stakeholder Requests
This artifact contains any type of requests a stakeholder (customer, end user,
marketing person, and so on) might have on the system to be developed. It may also
contain references to any type of external sources to which the system must comply.

2 funikovyuri: \r
ok, поправка принимается. Тем не менее - ты с этим согласен или нет?(insert vs add) \r
\r
Если исходить из того, что ХП и методы должны именоваться единообразно , т.е использовать а) одинаковые способы (регистры, "_" и т.д), б) одинаковые глаголы действия и в) однозначно показывать действие, то получаем следущее, например,для моего случая с "_":\r
\r
1. только "естественные" глаголы: \r
Методы: Add_User, Delete_User, Get_User_xxxx, Set_User_xxxx\r

ХП (лог.имя): Add_User, Delete_User, Get_User_xxxx, Set_User_xxxx\r
\r
2. только DML-глаголы: \r

Методы: Insert_User, Delete_User, Select_User_xxxx, Update_User_xxxx\r

ХП (лог.имя): Insert_User, Delete_User, Select_User_xxxx, Update_User_xxxx\r
[1](нарушает негласное "правило" в ООП (Java, VB и т.д), по к-му св-ва/методы интерфейса имеют префикс "Get" и "Set")[/1]\r
\r
3. смешанные глаголы: \r

Методы: Insert_User, Delete_User, Get_User_xxxx, Modify_User_xxxx\r

ХП (лог.имя): Insert_User, Delete_User, Get_User_xxxx, Modify_User_xxxx\r
[1](нарушает негласное "правило" в ООП (Java, VB и т.д), по к-му св-ва/методы интерфейса имеют префикс "Get" и "Set")[/1]\r
\r
т.е сплошные противоречия. Но мне, например, наиболее естественным, наименее противоречивым и самым легким в написании ("Add" vs "Insert", "Set" vs "Update" и "Modify", "Get" vs "Select") кажется 1-й вариант. Именно такой способ обычно практикуется объективно в наиболее профессиональных организациях, с к-рыми мне довелось работать. Что в общем меня в очередной раз убеждало в достоинствах этого способа, несмотряя на его ориентированность на ООП. Далее: я специально использовал "лог.имя" для ХП, чтобы показать, что можно использовать преобразование/трансляцию имен в CASE-средстве, т.е если датабейсеру хочется иметь DML-глаголы вместо ОО-глаголов в именах объектов той же модели данных или DDL. Те, кто хочет видеть "Get", "Set" в модели данных - используют лог.имена, а те, кто хочет видеть "Select", "Update" - используют физ.имена . Например, в PD есть функция преобразования Name-2-Code и Code-2-Name (Name/code conversion), использующая макроскрипты или таблицы подстановки для преобразования имен. А какой у тебя вариант именования? :о)\r
\r
2 Lepsik: \r
ID vs table_id vs TableID \r
\r
особенно в месте где FK table_id vs TableID vs Link_table \r
\r
На стр.1 это уже обсуждалось и были предложены конкретны способы (использование префиксов, регистров, "_") именования, см. посты Дата: 28 сен 03, 00:47, Дата: 29 сен 03, 05:09, Дата: 30 сен 03, 00:16 и ниже