VolochkovaЕсть ли какие то идеологические обоснования подчерков в именах полей?
Partner_Store_Name читается проще, но ItemID в начертании понтянее.
Спасибо.

Тому несколько причин.

Если нет нормальной IDE, то удобно в запросах выделять ключевые слова капитализацией. Типа select NAME from TABLE. Это иногда упрощает чтение больших запросов, но при этом, разумеется, использовать аналог CamelCase уже не получается, не удобно, так что приходилось использовать подчерки.

Кроме того, некоторые СУБД до сих пор не различают регистр таблиц и полей, а раньше многие даже не сохраняли капитализацию и переделывали запрос по собственной воле (вот точно помню, что Oracle таким отличался когда-то).

Вообще, судя по примерам, это еще небольшие БД. В действительно больших были бы еще и префиксы у таблиц (для разделения по доменам) и еще какие-нибудь странные вещи.

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

Сейчас, честно говоря, разумнее в БД использовать тот же стандарт кодирования, что используется на AppLayer. Т.е. если БД используется из-под C# - то так и поступать. Таблицы - классы, поля - свойства. Это упрощает чтение и mapping :)

P.S. Вообще, на мой взгляд, подчерки сильно замедляют чтение кода (особенно при обсуждении по телефону). А уж какой ужас разбирать код с подчерками, распечатанный на плохом матричном принтере (который их просто не пропечатывает). Но это все тоже привычки очень старых дней )

softwarerDPH3Если нет нормальной IDE, то удобно в запросах выделять ключевые слова капитализацией.
Хм. Удобства здесь мало для чтения и ещё меньше для набора. Имхо просто рудимент от компиляторов 70-х годов, когда зачастую знакогенератор уже поддерживал регистр, а вот софт ещё требовал "обязательно больших".

Ну, как всегда, дело привычки и личных предпочтений. Мне вот зачастую так удобнее. Особенно в "болтливых" диалектах типа DB2. Впрочем, у меня уже давно нет проектов с большим количеством кода на уровне БД. А когда были, так там обычно и какие-нибудь кодогенераторы выстраивались и прочая инфраструктура, которая заметно влияла на codestyle. Впрочем, при тысячах таблиц и десятках тысяч хранимок и при жестких ограничениях на длину идентификаторов приходится извращаться, да )

softwarerDPH3а раньше многие даже не сохраняли капитализацию и переделывали запрос по собственной воле
Вот на это хотелось бы посмотреть. Прямо-таки представляю себе, как СУБД ночью логинится в SVN и тихонько переделывает запросы по собственной воле.

Я про хранимки. Во времена двухзвенок я старался вообще не держать текстов запросов на клиенте, все в БД. А еще какой-то старый Oracle любил упорядочивать список полей во вьюшках по собственному усмотрению, дико раздражало )

softwarerDPH3Таблицы - классы, поля - свойства. Это упрощает чтение и mapping :)
А главное, думать не надо. Типичный подход однозвенного мышления.

Ну, сейчас в многозвенке про слой хранения вообще стараются не думать (и правильно, в большей части проектов там и думать-то не о чем). А там, где приходится думать - вопросы по именованию редко задают. А вот общий code style - вещь удобная, как ни странно )

softwarerDPH3Вообще, на мой взгляд, подчерки сильно замедляют чтение кода
Вопрос привычки, имхо. Некоторые даже в ALLCAPS почти не тормозят.

Вот я даже ALLCAPS предпочитаю подчеркам. Просто я при чтение кода подчерки тоже проговариваю (ну, привычка такая, еще с С), что сильно замедляет чтение.
Вкусовщина и традиции конкретного проекта/СУБД.