Есть в программировании люди, которых хлебом не корми - дай сделать систему настолько расширяемой и настраиваемой насколько это только возможно. Я уже упоминал про это косвенно в посте На будущее- но есть и частный случай такого подхода - чрезмерные абстракции с базами данных.
Суть ситуации в том, что люди намеряно сводят работу с базой данных до уровня insert, update, select, delete, создавая особо извращенные варианты доступа к этим самим данным. Любые - лишь бы не SQL. В итоге, понятное дело, без извращений в таких вещах очень сложно сделать простые с точки зрения запросов вещи. Ну например, счетчик посещений сайта и например ORM.
Алгоритм какой будет?
1. Выбрали данные;
2. Увеличили на 1;
3. Сохранили данные.
А что если на сайт почти одновременно зайдут 2 пользователя? 
Причем до шагов этого алгоритма они дойдут параллельно и в одно время. Т.е. 1-й делает выбор данных, потом второй, потом первый - увеличивает счетчик и т.п.? понимаете?
В самой базе все проще - UPDATE четотам SET `count`=`count`+1 WHERE четотам. И никаких глюков - потому что запросы будут выполняться последовательно.
Когда же копаешь глубже о причинах таких диких абстракций - оказывается, что все для того, чтобы:
Если заказчик захочет сменить базу данных скажем с MySQL на Oracle - то мы всего лишь переписали бы конфиг и все запалило на ура вместо того, чтобы переколбашивать весь сайт.
Я однажды не выдержал и поспрашивал всех кого знал, а сталкивался ли кто-нить из них с такой задачей - и оказалось что такое всплыло 1 раз на примерно 500-700 проектов, в которых участвовали опрошенные
Проблема эта в мире по на заказ (при разработке пакетных вещей - другие законы совсем, не нужно путать эти миры) - надуманная и определенно не стоит тех мучений и костылей, которые приходится делать в подобных системах.
Надеюсь, кому-то этот пост поможет перестать наступать себе на яйца при разработке. Помните: какой бы ни была по сложности задача смены СУБД - вы или фирма все равно на ней нагреетесь - заказчик хочет - заказчик платит