Есть у меня одна особенность. Я склонен к рефлексии. Так вот, довольно часто я анализирую свое поведения и стереотипы и пытаюсь разобраться, что повлияло на меня при принятии того или иного решения. Чаще всего подобные размышления возникают у меня тогда, когда я сталкиваюсь с какими-либо проблемами (в частности, связанными с работой или самоорганизацией).

Довольно часто в этих самых размышлениях я возвращаюсь к школьным годам. Мне кажется, что именно в этот период формируются стереотипы и модели поведения, которые в будущем влияют на нашу деятельность. Причем, многие из них – неблагоприятно. Для себя, я смог определить следующие проблемы, которые мешают нам быть эффективнее:

Ни для кого не секрет, что работа с базой данных занимает большую часть работы практически любого сайта. И именно работа с БД чаще всего является узким местом веб-приложений.
В этой статье хотелось бы дать практические советы использования MySQL.
Сразу оговорюсь:

• данная статья написана про MySQL, хотя общие вещи скорее всего справедливы для любой СУБД.
• все написанное в статье является моей личной точкой зрения, и не является истиной в последней инстанции.
• советы не претендуют на новизну и являются результатом обобщения прочтенной литературы и личного опыта.
  
• в рамках данной статьи я не буду касаться вопросов конфигурирования MySQL.

Проблемы при использовании MySQL можно разделить на следующие три группы(в порядке значимости):

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

Сколько я знаком с технологией Flash, столько же я хотел научиться ее использовать. Мне хотелось уметь рисовать мультики, интерактивные сайты, игры, работающие прямо в браузере.

Я ставил Macromedia Flash, качал уроки, шаг за шагом проходил их, но бросал, не дойдя и до половины. Отсутствие дизайнерских навыков давало себя знать. В общем я уже смирился с мыслью что не дано мне стать видным флешером. И невидным – тоже.

Недремлющая компания Microsoft примерно с год назад представила свой вариант решения проблемы создания «красоты» в Web под названием Silverlight. Первая его версия была мною скачана, осмотрена и для собственного применения забракована. По сути она мало чем отличалась от обычного Flash, «только в профиль».

Но свежий ветер маркетологии принес к нам из-за морей свежую весть – оказывается, будущее будет за так называемыми Rich Internet Applications, то есть (грубо говоря) программами, которые будут одинаково работать как онлайн, так и при полном этого самого онлайна отсутствии. И самое интересное, что уже популярный и знакомый AJAX – это совсем-таки неудобно для создания RIA, а нужно нам нечто совсем другое. Вариантов «другого» оказалось немало. Многие компании ринулись строить «другое» на базе того что у них уже было. Так появились JavaFX, Adobe AIR, Microsoft Silverlight 2.0 и другие…

Из всего вышеперечисленного, именно Silverlight 2.0 пришелся мне по душе. Он разительно отличается от первой версии и предоставляет куда больше возможностей. При этом, даже такой закоренелый программист как я – может его с легкостью использовать без знаний о дизайне.

Все люди, вовлеченные в проектирование различных БД, думаю, нередко задаются вопросом о нужной структуре. На данный момент, есть два варианта хранения данных, каждый из которых, в свою очередь, имеет ряд своих недостатков.

1. Объединенное хранение

Например, есть таблица типов объектов (ObjectsTypes), таблица самих объектов (Objects) и их свойств (ObjectsFields). По желанию, можно хранить еще и типы полей-свойств, это не принципиально.
Связи между таблицами определены однозначно (объект имеет один тип (typeID) и ряд свойств, связанных с родительским объектом полем objectID), между объектами связь осуществляется и с помощью древовидной структуры (родитель ← ребенок) и путем заведения отдельной таблицы (ObjectsRelations) для сетевой структуры, в которой дочерний элемент может иметь несколько родительских.

2. Индивидуальное хранение

Если представлять эту реализацию на примере, то для хранения блогов нужна таблица Blogs с полями, относящимися к нему, таблица BlogsTopics, хранящая посты и их свойства, таблица BlogsVotes, содержащая все пользовательские голоса и т.д. Можно до бесконечности развивать этот пример — смысл такого хранения в том, что для каждого типа данных создается своя таблица (если нужно, то несколько).

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