Database tables and columns naming conventions

Once again I've got to explain what I think about database tables and columns naming conventions. This time, I've decided to write down my points, to be able next time just to give a link :).

Starting with tables - main question is plural or singular form should be used. Main point in favor of plural form is something like "it is a collection of entities, so it must be named in plural form". Singular form is preferred when you want to write query like "where user.id = ", and not "where users.id = ".

When it comes to columns' names, there are much more arguing about it. Main one is about primary key - should it be ID or entity_id. In case you've used plural form for tables, it become more pleasant in queries - "where users.user_id = ". Next bone of contention is about short forms in columns' names - could you name it like userGoodsCnt, or you must name it like amount_of_goods_in_user_cart.

It's funny to notice that usually, ones that love plural form of tables' names and long version of primary key prefer long version of columns' names too. Why do they love long names so much? In most cases they say that it's because "database schema must be as much readable as it could be". It is very important to have readable and pretty much self-explanatory schema, then why others disagree? Ones that like short forms says that "it is _understandable_, and it is shorter. save a byte - save a tree". One more point - description of column or table could be kept near it, not necessarily in name - in description, in repository, in comments... 

From my point of view, it is all about when and how you work with schemes. Either you usually look on DB chart, or DB schema or some entities' relations graph... in this case you prefer long, self-describing names, since comments are hidden at this time. And, what is usually much more important, you look at this chart from time to time, either you are DBA with a lot of such schemes, or it's just not your primary job - you just refer to schema sometimes, so you do not need to remember it and want to get all information from just one look. On the other side are those who work with tables' and columns' names many times a day, those who write code and queries. They usually keep whole DB schema in mind, and since they write all those names with their own fingers - they want it to be as short as possible.
First group are architects, who do not write code, technical directors and so on. Second are developers and coders.

Summary: if you are a leader and architect, do not forget about those who will work with schema every day - do not spoil their comfort in favor of pleasure look of DB chart. Developer's comfort is very important - not lesser then yours. But they spend much more time with DB - don't forget about it. It doesn't mean that table could be named as table1 with columns A,B,C - no way.

I myself prefer to name tables in plural form, but to name columns as short as possible. It's because I use ORM, so I do not usually see ugly queries like "where users.id = ", but I use forms like "select from users where name like" - it is ok with me. But when it comes to columns' names - I try to keep it as short as possible, as long as it is understandable to those, who work in the same project. I'm pretty much sure, that if you can't spend time to read and understand DB schema with shortened forms (like usr instead of user) - then you'll not have enough time to make something good to project's technical development.

API or not API

Столкнулся недавно с проблемой разделения функционала на API уровень и уровень приложения. Не то чтобы с самой проблемой, но с проблемой донесения своего видения. Опять на повестке дня один из вопросов проектирования.

Попробуем рассмотреть известные приложения. Для начала разберем клиентское приложение, не связанное с вебом - например, электронные таблицы.
Что относится к уровню API? Ну, базовые операции над ячейками - прочитать/записать. Что еще должно быть доступно макросам, например? Выделение, операции над группами ячеек - копирование, заполнение. Создание объектов - графиков, например. Если в общем - практически все операции с данными, включая получение из внешних источников.
Что не должно относится к API? Внешний вид окна приложения - это настройки системы.
Спорные вопросы:
Сохранение и загрузка файлов - с точки зрения безопасности, лучше в API к этому доступ не давать, хотя с точки зрения проектирования возражений особых нет. Это тоже работа с данными, и скрипт обновляющий данные из сети, обновляющий графики по новым данным, может иметь возможность и сохранить результат своей работы.
Настройки расположения кнопок и панелей - на мой взгляд, это никак не должно относится к API. Контекст работы с кнопками подразумевает наличие GUI, и относится только к нему, и без GUI не имеет смысла. API для работы с данными, в свою очередь, должно работать без знания об интерфейсе - как будто его нет, или точнее, если его нет, оно должно работать так же. А значит втаскивание таких вещей в API есть грубое нарушение контекста, которое приносит головную боль как разработчикам, так и тем, кто пытается пользоваться этим функционалом. Ведь как бы разработчики не старались, все равно весь функционал GUI втащить в API не получится, значит остануться ограничения, которые будут требовать убрать - "раз сказали 'a', скажите и 'б'", и начнется напихивание в API всякого рода магии для предоставления функционала, которого не должно быть, магия будет давать сбои, пользователи будут недовольны, а корень проблемы в неверном проектном решении.

Рассмотрим теперь другой пример - веб-система, у которой есть и веб-приложение и API. Например, Google Analytics, хотя таких много.
Итак, что же есть в API: операции получения данных в самых разных разрезах - куда больше возможностей, чем в веб-приложении, надо заметить. Оно и понятно - возможности сначала появляются в API, и только потом кочуют в интерфейс, когда их обкатают и если признают популярными. Возможность просмотреть настройки - профилей, сегментов, целей.
Чего нет в API: создания / изменения сегментов и целей, почему - вопрос, видимо, все-таки не востребовано. Получения настроек интерфейса.
Вопрос: почему же нельзя из другого приложения получить пользовательские настройки в GA? 
В данном случае, это пример корректного разделения контекстов - пользовательские настройки одного веб-приложения не должны быть доступны из другого. Даже если на первый взгляд кажется, что это глупость, и пользователю от этого будет неудобно - стоит подумать еще раз и еще. Аргумент приводимый "за" - например, в приложении для мобильных устройств пользователь наверняка захочет увидеть тот же dashboard, что он настроил в основном интерфейсе. Звучит логично. К сожалению, только звучит. Во-первых, пользователь в любом случае не увидит привычного dashboard - в силу специфики мобильных устройств, и ему или будет неудобно, или он перенастроит его под мобильное представление. А если dashboard единый - то он испортит свои настройки в основном. Делать же галочки типа "разделять мобильные и основные настройки" - глупо, в настройки заходят меньше процента пользователей. Во-вторых, создатели других веб-приложений тогда радостно наступят на эти же грабли - тупо будут брать настройки dashboard из имеющегося профиля, со всеми проблемами типа синхронизации, неполной поддержки и т. п. И в результате, вместо набора хороших приложений от сторонних производителей получится куча мусора. В-третьих, если такое появляется в API, это автоматически замедляет развитие собственного интерфейса - надо ведь теперь всегда поддерживать обратную совместимость, причем не только на время обновления, а достаточно долго держать обе версии в бою. А сомнительный плюс только один - пользователь сможет увидеть свои настройки (в другом виде, вряд ли узнаваемом и удобном) в других приложениях.
Итого: из смешения контекстов вырисовывается много проблем, как для разработки, так и для пользователей. И не надо забывать, что проблемы разработки - это всегда в ближайшем будущем проблемы пользователей.


Возвращаемся к началу - где же провести границу между тем, что должно быть в API и тем, что не должно? Не претендую на последнюю версию ответа :), т.е. возможно со временем и я изменю свою точку зрения, но в настоящий момент, думаю правильные критерии таковы:
- в API должны быть все операции с данными, которые не требуют обязательного контроля человека - все операции чтения/записи данных, максимально гранулировано
- в API должен быть максимально полный функционал управления процессами в приложении - если расчеты, проводимые в приложении имеют настройки, эти настройки должны быть доступны
- в API не должно быть ничего о пользовательских настройках, не имеющих отношения к данным и процессам их обработки, т.е. все аспекты визуализации - только через интерфейс
- в API не должно быть ничего о пользователе - информация о нем, явки-пароли и т. п. - только через интерфейс, а также все его настройки уведомлений и прочее - тоже; в крайнем случае, это можно сделать через отдельное API управления пользователем, но смешивать с API данных - нельзя

Надо не забывать, что интерфейс построен поверх API. И другие приложения должны быть тоже построены поверх API, а не поверх интерфейса, который поверх API. Не надо думать, что созданный интерфейс единственный верный. Даже если никто не сделает лучше - пусть пробуют. А еще, очень важно, не забыть, что даже если вам кажется, что все остальные делают плохо - это не значит, что у них нет довольных пользователей. Угодить всем невозможно, зато можно сделать (или способствовать появлению) такого разнообразия вариантов, что удовлетворит почти всех.