КапюшонКак вы предпочитаете именовать поле первичного ключа (integer): StatusID или ID (ProjectID или ID, ClientID или ID...)
Я предпочитаю ID, т.к. достигается единообразие, упрощается написание клиентского кода, не дублируется имя таблицы (мы же не включаем имя таблицы в каждое поле)...
Подобно ID в моей системе обозначений существуют поля Title и Descr.
Правда, ID может быть зарезервированным словом, это недостаток данной нотации.

Ваша точка зрения?
Я предпочитаю просто id. Дублирование имени сущности внутри нее - излишне. А вот глобальные имена стараюсь делать достаточно длинными. Помню, как наелся из-за этого с какой-то древней версией ErWin, который упорно отказывался понимать, что поле в дочерней и родительской таблицах может по-разному называться. К счастью в современных версиях с этим вроде бы порядок. Вообще, это не играет существенной роли. Главное, чтобы во всем проекте наблюдалось единообразие.

sparrowЕсли ID, является первичным ключём, то настоятельно советую впереди ID добавить имя своей таблицы, А чем эта настоятельность аргументируется? Собственной привычкой или какими-то рациональными соображениями?

sparrowBogdanov Andrey >
Наверно сказалась привычка 'древней версией ErWin',
рациональное соображение в том, что из SQL комманды, почти сразу можно понять что и с чем связано, когда разбираешься со слабо документированным приложением.
На мой взгляд существенным минусом является значительное удлиненние идентификаторов (ведь если обязательно требовать вместо Id писать ParentDocStatusId, то тогда и вместо Name надо писать ParentDocStatusName и т.п.). Это сильно сказывается на читабельности кода в отрицательную сторону. Короткие имена (но не аббревиатуры) значительно повышают скорость чтения кода. Ну а в местах, где восприятие имени может быть неоднозначным (например, в запросе объединяющем несколько таблиц) всегда можно использовать полное имя (ParentDocStatus.Id).
Кстати, в других языках программирования почти никогда не расширяют локальные имена именем объемлющей сущности. В любом классе по работе с файлами надутся функции open и close, но почти никто не называет их fileopen и fileclose.

sparrowBogdanov Andrey >
понятно,
'ParentDocStatusId' -в принципе ничего страшного, можно и длиньше Длиньше можно, но время затрачиваемое на понимание кода в таком случае прямо пропорционально (а скорее всего даже пропорционально квадрату) длины идентификаторов. Ведь вместо того, чтобы увидеть просто Name я вынужден буду "прочитать" весь идентификатор до конца, чтобы выделить в нем смысловую часть. Это становится совсем приятным занятием, если индентификаторы приведены к одному регистру (лично меня особенно верхний регистр утруждает).

sparrowНаверно это Forenkey на DocStatusId таблицы DocStatus - тогда его, наверно, можно назвать ParentId.
Древовидные связи типа ...Id - Parent...Id - Я не говорил ни о каких древовидных связях. У меня есть табличка ParentDocStatus (вы же сами сказали, что название сущности просто Status - вас не устраивает, вот я и дополнил его - имеем "статусы документов верхнего уровня"). В этот табличке есть идентификатор и наименование. По вашей рекомендации к названиям колонок добавляем имя таблицы вот и имеем ParentDocStatusId, ParentDocStatusName и т.п.

softwarer Bogdanov AndreyВ любом классе по работе с файлами надутся функции open и close, но почти никто не называет их fileopen и fileclose.
Потому что почти никогда не требуется писать код наподобие


Если бы такой код был типичным - мгновенно восторжествовал бы стиль


Честно скажу, что для меня вторая строчка ничуть не понятнее первой. Попробую разобраться.
Очевидно мы имеем некоторую сущность "Object". У этой сущности есть метод Open и вот тут расширение имени метода до OpenObject совершенно бессмысленно. А вот дальше - непонятно. Видимо наш метод Open возвращает какой-то еще объект. В этом случае название Open скорее всего не адекватно. Или у нас метод занимается не открытием объекта, а открытием какой-то другой сущности ассоциированной с объектом. В этом случае и название должно было бы быть что-то типа OpenStream. И т.д.