Только не кидай сразу тухлыми помидорами: очень знакомая фамилия, но что-то с утра не могу упорно вспомнить КТО ЭТО ТАКОЙ?

.. Надо стараться стать таким как он. Знает как себя продать.

А как он себя продает и вообще что он продает? Семинар по DBMS/SQL или свой авторитет (то, что он ее читает) что ли? Тоже мне добро...

.. Имена таблиц в разговоре называет во множественном числе. В доках в единственном.

На самом деле это спор типа HW. Аналитики считают, что корректнее называть сущности и, наверное, соответственно таблицы в единственном числе (я с ними согласен). Я и еще один наш разразработчик помню флеймили по этому поводу с БП Марголиным, потом еще Джо Целка подключился, короче понеслось... Целка ни чью сторону особо не занимал, а больше примирял нас, называя методистами - типа, ребята, какая нах... разница, хоть х... обзови. У БП Марголина аргумент был один: таблицы содержат строки, значит имя должно быть во множественном числе. Когда я ему сказал, что в вообще в таблице может быть и 0 строк, то он мне сказал, что зачем такая таблица без строк. Короче, ДБА он и есть. Я использую в единственном числе - это в CDM, что понятнее заказчику (сущнсоти "Сотрудник", "Товар" и т.д), а в PDM можно букву "s" легко прицепить в том же PD по желанию, если БД потом будет дорабатываться на стороне. У нас все имена в единственном числе потому что, например, "Tovar" (особенно если их сотня другая) проще запоминается и понятнее, чем "Tovary" или "Tovari" или "Tovars" (видал я и такое уродство). То же самое и с английскими названиями - проще, т.е без "-s", "-еs", "-ies" и т.д гемороев В общем правила именования объектов обязательны

Стоит ли на него идти? Однозначно да. Посмотри как себя вести надо. :)

Да, спасибо, сейчас уже билет за 1000$ купим и слетаем на его "концерт" в Канаду :о)

2 папа Карло: \r
все просто.... логический дизайн - единственное число. физический множественное. таблица с нулем строк? легко! это все еще множество, просто с кардинальностью 0. :) только плиз! горячие парни, не надо спорить со мной и доказывать что это не так. мне хорошо уже сейчас \r
\r
Спорить, доказывать тебе... и забесплатно? Нет уж. У тебя либо есть аргументы, либо у тебя их нет. То, что это все еще множество - это не тянет на сильный аргумент. То, что имена во множественном числе вызывают к жизни лишнюю работу по дописке "s" - факт. Далее, не понятна связь между кратностью (кардинальностью) и именем. Объясни, пожалуйста. Например, в математике множества вообще обзываются одной буквой, например, Β . Конечно, при объяснении детям или школьникам азов теории множеств говорится: "Это, дети, множество яблок - \'Яблоки\'". Так ты с детьми или ты с серьезными мужиками (математиками)? :о)\r
\r
Дейт кстати также делает.... в логическом дизайне использует единственное число в физическом множественное. внутри оракла самые крутые дизайнеры тоже так-же делают. Только не надо приводить оракловские примеры баз, они писаны Ява девелоперами, а не проектировщиками или математиками. \r
\r
Нет, я дядю Криса уважаю, конечно, но своя соображаловка на что дана?\r
\r
\r
2 funikovyuri: \r
Здорово, если вы не против, давайте сформулируем основные стратегии именования, а то \r
здесь мы так к чему то определенному и не пришли \r
\r
В общем все правильные идеи уже были высказаны в Naming Convention. Темы для обсуждения практически не осталось. Могу только согласиться, что основные принципы это:\r
\r
1. максимальная простота восприятия разработчиком\r
2. глобальная однозначность (смысловая, физическая)\r
3. удобство обращения - даже имя указывает на тип объекта (когда тип не ясен из контекста)\r
\r
Возможные примеры:\r
\r
сущность : Работник_Департамента\r

таблица : t_department_employee, tbl_department_employee\r

вид : v_department_employee_salary, vw_department_employee_salary\r

ХП : usp_find_department_employee, uxp_find_department_employee (расширенная), ...\r

триггер : tg_department_employee_salary_delete, tg_department_employee_salary_update, ...\r

функция : f_get_department_employee_salary\r

PK : pk_department_employee\r

FK : fk_department_employee__department, т.е fk_ <child>__<parent> \r

кластерный индекс (уникальный) : uc_department_employee, т.е uc_ <table> \r

некластерный индекс (уникальный) : unc_department_employee__fname_lname, т.е unc_ <table>__<idxcol1>_<idxcol2>_.. \r
неуникальный - соответственно без "u"\r

ограничение : chk_department_employee__salary, т.е chk_ <table>__<column> \r

правило : r_employee_salary\r
\r

класс BCB/Delphi : TDepartment_Employee\r

класс VB : clsDepartment_Employee\r

атрибут/св-во : nEmployee_Salary (число), sEmployee_Name (строка), bEmployee_Salary (бул), ...\r
также можно использовать префиксы, показывающие область действия\r

константа : MAX_EMPLOYEE_SALARY, MAX_EMPLOYEE_NAME_LENGTH\r

метод : Get_Department_Employee_Salary, Set_Department_Employee_Salary, ...\r
\r
Кстати, многих разработчиков раздражает обилие присутствия символа "_" буквально до тошноты, но все-таки имя "Get_Department_Employee_Salary" гораздо легче воспринимается, чем "GetDepartmentEmployeeSalary" особенно в конце рабочего дня и когда этих имен штук 30.\r
\r
2 vdimas: \r
Но вот мнения интересны (особенно из-за того, что в некоторых фирмах этот вопрос возводится в разряд особенных, и порой затмевает более насущные темы, напр. смысл правильно обозванных конструкций) \r
\r
А что имеется в виду под "конструкцией"?\r
\r
--\r
З.Ы. Наверное, в меня полетят тухлые помидоры поскольку я по большей части пользуюсь правилами именования, предложенными Майкрософтом и Борландом. Все так, но зато это объединяющий фактор, т.к многие разработчики ими пользуются

2 папа Карло: \r
Помидоры в тебя не полетят. именуй как хочешь. :) \r
\r
Не полетят? А жаль. Я хотел из них салатик настругать, заправить прошлогодним майонезом и заморозив послать дяде Билли. Так что же с Кимбалом - как он себя продает? :о)\r
\r
МС говоришь? :) а как у МСа называется системные таблицы? sysobject говоришь? :) ........\r
Странно что они рекоммендуют одно, а делают другое? Тогда встает вопрос, если они сами никогда этого не делали, то какого фига учить других (Б.Шоу - Кто знает, тот делает, кто не знает тот учит)? \r
\r
Ну, учили, а точнее рекомендовали и правильно делали с просветительско-воспитательной т.з. Другое дело, что их рекомендации по поводу не правил , а конкретных именований (типа tbl* и т.д) часто вызывали критику у сообщества разработчиков, т.к порой менялись в одних и тех же источниках, были не очень однозначными или интуитивно понятными и т.д. Вот это пожалуй важно, а не то, что они не следуют своим же рекомендациям. Это их "невежд" законное право. Так что афоризм классика здесь неуместен\r
\r
MSDN Library \r
The main reason for using a consistent set of coding conventions is to standardize\r
the structure and coding style of an application so that you and others can easily\r
read and understand the code.\r
\r
Good coding conventions result in precise, readable, and unambiguous source code\r
that is consistent with other language conventions and as intuitive as possible.\r
....\r
When selecting names for objects, properties, methods, and events, choose names\r
that can be easily understood by the users of your component. These elements comprise\r
the programming interface of your component — the more clear you make their names,\r
the more usable your code will be.\r
\r
интересно на что она дана? для меня множество с кардинальностью ноль все еще множество. ... \r
\r
Для меня тоже, но только с кратностью нуль. И, пожалуйста, не засоряй уж русский язык - словарь Ожегова:\r
\r
КАРДИНАЛЬНЫЙ, –ая, –ое; –лен, –льна (книжн.). Самый важный, существенный, основной. К. вопрос. \r
| сущ. кардинальность, –и, ж.\r
\r
Ты делаешь следующий логический "пассаж": раз во множестве (таблица) содержится 0...N объектов, то значит его имя должно быть во множественном числе. На основании чего ты его делаешь?\r
\r
... Называть таблицы одной быквой ты разумеется можешь. :) флаг в руки. Именование объектов, энтитей и таблиц имеет свои подходы. смешивать их не надо. \r
\r
А где ты увидел, что я их смешиваю? Можно предположить определенные "требования" (см. выше: понятность, однозначность, удобство, уникальность и т.д) к именам объектов модели/схемы. Попробуем порассуждать для тех же таблиц:\r
\r
понятность - наврядли имя во множественном числе является более понятным,\r
чем то же самое имя, но в единственном и особенно с использованием префикса;\r

однозначность - см.выше;\r

удобство - имя во множественном числе, а особенно если имя - английское слово\r
требует доп.работу по дописке, наприммер, "y", "i" или "s", "ies" соответственно;\r

уникальность - такая же как для имен в единственном числе\r
\r
хехее..... знаешь, математика наука точная. :) там в реляционной алгебре есть определения и прочие вещи. :) a set of emloyee or a set of employees? \r
\r
Ты подменяешь рел.алгебру английским языком. Кстати, в рел.алгебре используются характерные для математики имена отношений/кортежей - A, B, .., R, S (когда дается теория) и имена отношений в единственном числе (когда даются конкретные примеры). См., например, Реляционная модель данных , а также книги, например, Коннолли, Ульмана (хотя этот также объектник) и др.\r
\r
и последнее. пойдя на интервью если ты попадешь к чистому датабазнику типа меня и назавешь таблицу в единственном числе можешь получить облом на раз. :) и наоборот попав к датабаз девелоперу пришедшиму со стороны ООАД и назвав во множественном также получишь облом. :) \r
\r
Как уже сказал "vdimas": и слава богу, что получу облом - это позор работать с таким воинствующим дубинушкой , к-рый исподтишка "обламывает" собеседуемого профессионала только за его правила именования, не выяснив хотя бы почему тот именует объекты по-другому. В конце концов это ведь только собеседование, а еще не проект :о)\r
\r
\r
2 vdimas: \r
я стараюсь в рамках одного проекта придерживаться правил разделения или заглавными символами или символом \'_\'. Чисто механически давить и Shift и \'_\' - элементарно неудобно. :) А мне как программисту именно приходится не столько смотреть на них "в конце" дня, сколько именно "давить" в течении оного. :) \r
\r
Давить на кнопки вообще очень трудно. Интересно, когда же изобретут устройство если не для создания исполнимых компонентов сразу, то хотя бы для передачи мыслей разработчика в CASE или IDE? :о)\r
\r
EmployeeName (employee_name) - тип - "IdentificatorType", ясно из смысла. \r
EmployeeNum (employee_num) - число, целое, "CounterType" \r
CustomerID (customer_id) - тоже число, "CustomerIdType". \r
Из примеров это неочевидно, но вполне может стать очевидным из спецификации (к тому же, повторяющейся от проекта к проекту). \r
\r
Согласен, что имена типа EmployeeName или CustomerID "говорят" сами за себя. Но представь, что есть, например, такие атрибуты - EmployeeZip (почтовый индекс) или EmployeePhone (№ его телефона), т.е уже не так однозначно как в первом случае. Т.е в моем случае префикс подскажет тип данных. А в твоем случае, видимо, придется "приделывать" постфикс для типа, например, EmployeeZipCode и EmployeePhoneNumber, что требует чуть больших усилий :о)\r
\r
Переопределения типов помогают "управлять" кодом. Никто не застрахован от доработок ТЗ из-за изменений требований. Такой подход уменьшает (сводит на нет) трудоемкость по изменению типов в структурах. ... \r
\r
Т.е ты хочешь сказать, что может случится менять Integer на String? Тогда да, в моем случае придется менять не только тип, но еще и 1-2 буквы префикса, а в твоем случае, видимо, несколько букв постфикса\r
\r
.. Тоже самое относится к БД. Применять user types - это правило хорошего тона (да к тому же - это дополнительная мета-информация). \r
\r
А какие у тебя критерии для введения UDT? По-мойму кажется Целка сказал, что UDT следует вводить, когда, например, столбец (домен) мигрирует хотя бы один и более раз -ИЛИ- несколько столбцов будут иметь один (общий) домен. Я с ним согласен. Однако несколько десятков, а в крупных БД порой под полторы сотни UDT/доменов создают определенные трудности на этапе проектирования. Например, в том же PD (в ErWin их можно группировать) все домены содержатся в одном общем пакете. С какой-то т.з может это и правильно, но очень неудобно потому что есть домены, к-рые используются только в одном "логическом" пакете.\r
Поэтому закономерно возникают те же требования к именованию доменов : простота восприятия, однозначность, назначение (для чего этот домен, тип данных), а за одно и таким образом их сортировку по имени в дереве. Позволь спросить: как ты именуешь UDT/домены?\r
\r
порой как спросишь, так и не понять - в шутку или всерьез? \r
ЛЮБЫЕ конструкции любых языков (DDL, SQL, C++, ...) \r
\r
Почему в шутку? Я вполне серьезно спросил. Имелось в виду: какие именно конструкции :о)\r
\r
Я имел реальный печальный опыт, когда на одной из фирм жестоко придирались к моей привычке оставлять скобку \'{\' на той же строке (т.е. не переносить ее), да и не нравились мне всевозможные node_map_key_t ( суффикс _t в с++ традиционно используется для системных или платформенно-зависимых типов, но никак не для прикладных). ... \r
\r
А чем их скобка не устраивала? Читабельность кода от этого что ли падала? У нас, например, на это дело вообще чхают, т.е у каждого свой стиль написания кода: одни ее переносят, а другие не переносят, но никто даже время не будет тратить на то, чтобы ее под себя переносить в десятке другом определений классов. Все определения исходно генерятся CASE и программисты, к-рые пишут тела методов все подстраивают под себя сами: переносы скобок, отступы, заголовки, комментарии и т.д. Главное - функциональная суть кода, его быстродействие, надежность работы и т.д\r
\r
.. Огромное количество доставшегося мне кода, правильно оформленного и названного содержало в себе порой элементарно неграмотные или крайне неэффективные решения. В процессе зачистки багов и исправления общей кривизны понаставил, панимаешь, скобок без переноса. ... \r
\r
А какое отношение имеют правила именования или стиль написания кода (перенос "{", отступ и т.д) к грамотности или эффективности , например, в C++?\r
\r
\r
2 aag: \r
Вас не затруднит указать, что это за правила? У Борланда в наименованиях символ "_" практически не встречается, за исключением "привнесенных" имен и констант (ADO, WinAPI напр.). У MS же для MSSQL я вообще не слышал о naming convension. Судя по их системным процедурам, там нет не только никаких правил именования, там даже стиль разный - в зависимости от автора. Т.е. вообще конь не валялся... \r
\r
Во-первых, я и не говорил, что "_" - это от Борланда. Имелся в виду, например, префикс "T" для типов. "Судя по их системным процедурам,.." - я уже ответил папа Карло , см.выше. Одно дело рекомендовать полезные правила, а другое дело - самим следовать им. Это разные вещи и первое (хорошо) не связано со вторым (не очень хорошо) хотя определенный нехороший "пример", конечно, Майкрософт подает и вопросы это вызывает\r
\r
Вопрос же о множественности/единствен. наименования таблиц - по-моему второстепенный. ... \r
\r
Второстепенный или первостепенный - это не столь важно, т.к есть тема для обсуждения, она также имеет отношение к практическому предмету (именам/именованию). Так что почему бы нам ее не пообсуждать с папа Карло ?\r
\r
.. Более важным является унификация и единообразия всех названия - для таблиц, хп, вьюх, полей и переменных и пр. \r
\r
Вот-вот, поэтому почему бы не добавить что-нибудь или покритиковать уже высказанное :о)

2 папа Карло:
больше не на что тыкнуть не нашел? :) я давно говорил что с русским языком у меня проблеммы. ты даже помоему говорил что не заметил, а вот теперь твое мнение поменялось? слово "кардинальность" используется 90% дата людбми с которыми я общаюсь (включая русских). важно что ты понимаешь о чем там сказано, ведь так? :)

Так-то оно так, но я ж от доброго сердца, искренне, не чтобы "тыкнуть", а чтобы и тебе сделать хорошо (грамотность) и ИТ-языку (чистота) тоже. Что касается cardinality , то может не "кардинальность", а скорее "кардиналити"? Я сам этим словом активно пользовался в 90-х гг, но постепенно сленг ("табла", "констрейнт", "вьюшник", "мультиплисити") у российских спецов выдыхается и сам по себе и в процессе общения их друг с другом. Приходится в конце концов использовать официальную русскоязычную ИТ-терминологию. Между прочим в ООП сленг изначально не прижился потому что "class" однозначно "класс", "property" - "свойство", "method" - "метод", а "interface" - "интерфейс". Кстати, в переводе Кодда нет ее (cardinality) вообще. Там есть тип связи (ассоциации), например, 1:N. А так, конечно, ты прав: можно говорить и "ж..па 1:N" или в этом духе - все равно люди догадаются. Но все же... :о)

а там голический или физический дизайн? ;) в логическом единственное число используется :) а физический дизайн начинается в том месте где появляется специфика конкретной СУБД. :)

Там непонятно какой дизайн или уровень. Там нет спецификации конкретной СУБД, но зато есть именно таблицы со строками , например



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

Во-первых, я и не писал и даже не намекал на тебя, что конкретно ты персонально дашь отлуп. Во-вторых, "облом" означает отказ и даже не важно будет этот отказ сделан исподтишка (да, "исподтишка" не было!) или собеседователь скажет в лицо почему было отказано собеседуемому. Главное, что было отказано по причине использования последним других правил именования :о)

---
З.Ы. А ты так и не расскажешь нам, что там вытворял мистер Кимбл на лекции? Сам же заинтриговал и молчишь.. :о)


2 aag:
См. выше. В отношении T-SQL я не встечал ни правил (от MS), ни примеров следования им.

То, что Майкрософт сама не следует декларируемым ей же правилам это уже все поняли и знают, но это не является аргументом, что эти правила именования ( правила , а не конкретные префиксы типов объектов и т.д) плохие или что не следует использовать правила именования при проектировании БД под MSSQL. Что касается конкретных примеров именования, то они есть:

Writing Readable Code (BOL):
Define and use a style convention for object names consistently. Two typical
conventions are:

Capitalize the first letter in each name part; do not separate name parts
with underscores: TableName.


Make all characters lowercase and separate name parts with underscore
characters (_): table_name.


MSDN Library также содержит следущие источники, непосредственно относящиеся к правилам именования:

Coding Techniques and Programming Practices (Technical Articles, February 2000)

Naming Conventions for Microsoft Access (Backgrounders, May 25, 1994)

Data Design in Visual FoxPro (Backgrounders, October 1997)

Visual Basic Coding Conventions (Visual Basic Concepts)

VBScript Coding Conventions (Visual Basic Scripting Edition)

Microsoft Foundation Class Library Development Guidelines (Backgrounders, March 31, 1997)

Writing Solid Code (Microsoft Office 2000/Visual Basic Programmer's Guide)

6.8 Naming Conventions (Visual J++ Documentation)
...и т.д

Лично мне представленные тобой здесь на суд божий правила именования - не нравятся. Не нравятся вообще, полностью. Однако, - в отличии от vdimas - я не хочу пытаться обьяснить это неудобством набивания, красотой и пр. Мне просто не нравиться и я не собираюсь как-то оправдываться.

Приведи, пожалуйста, тогда свои правила или примеры именований. Сразу увидим отличия и станет ясно почему не нравятся :о)

Сила naming convention в том, что они не обязаны нравится или нет. Но обязаны быть логичными и единообразными. Именно поэтому вопрос о единственности/множенственности я считаю вторичным. Просто главное, чтобы все сущности именовались одинаково.

Но необязательно, чтобы сущности и классы -или- ХП и методы именовались одинаково. На это есть причины. Также необязательно, чтобы классы в VB и Java именовались одинаково. И даже на это есть причины

Для себя я в Delphi придерживаюсь стиля Borland; с MSSQL сложнее - в силу исторических причин у нас нет единообразного стиля.

Что-то я смотрел вчера документацию, например, к Delphi 7, но тоже не нашел выделенных топиков, посвященных правила именования от Борланда кроме рекомендации для использования префикса "Т" и общих рекомендаций для методов:

DevGuide: Creating Custom Components , Naming methods

Delphi imposes no restrictions on what you name methods or their parameters.
There are a few conventions that make methods easier for application developers,
however.
.... It is a good idea to make your method names clear because people unfamiliar
with your code (and even unfamiliar with coding) might have to use your components.

Here are some suggestions for making clear method names:

Make names descriptive. Use meaningful verbs.
A name like PasteFromClipboard is much more informative than simply Paste or PFC.
Function names should reflect the nature of what they return.
Although it might be obvious to you as a programmer that a function named X
returns the horizontal position of something, a name like GetHorizontalPosition
is more universally understandable.


As a final consideration, make sure the method really needs to be a method.
A good guideline is that method names have verbs in them. If you find that
you create a lot of methods that do not have verbs in their names, consider
whether those methods ought to be properties.


хотя "naming convention" встречается довольно часто:

DevGuide: Programming with Delphi , Naming menus

As with all components, when you add a menu component to the form, the form
gives it a default name; for example, MainMenu1. You can give the menu a more
meaningful name that follows language naming conventions. .....

... Множественное чилсо мне как-то кажется более удобным.

Удобным может казаться и рисование задницы ASCII-кодами в заголовках файлов исходников или еще что-то в том же духе. Я же просто привел аргументы , что имена во множественном числе: а) не оправданы с т.з какой-либо логики, б) создают "неудобства" (надо дописывать "s"). Вот и все :о)

2 All:
Еще один интересный, а может и не очень момент или вопрос. Я часто просматриваю чужие ER-модели/схемы и давно заметил следующие отличия в использовании глаголов при именовании ХП (я опустил здесь префиксы типа "usp_"), например:

ХП, к-рая получает/выбирает строку: Get_xxxxx -vs- Select_xxxxx

ХП, к-рая добавляет/вставляет строку: Add_xxxxx -vs- Insert_xxxxx

ХП, к-рая изменяет/обновляет строку: Modify_xxxxx -vs- Update_xxxxx

т.е в одном случае используются "естественные" глаголы (get, add, modify), а в другом - глаголы из SQL DML (select, insert, update). Также встречаются и их комбинации, например, Get_, Add_, Update_ и т.д
Хочется услышать ваши предпочтения для именования ХП и, возможно, какие-то объяснения по поводу выбора. Господа, прошу высказываться! :о)