Building iPhone Apps with HTML, CSS, and JavaScript
WAP IS BACK!
Хорошей DB должно быть монго
Много-много лет назад, великий гений, коим я, несомненно, являюсь, осознавал неуместность использования реляционных баз данных в веб-программировании и регулярно травил пхп-программистов, которые любили писать, например, логи в базы.
И действительно, даже при разработке «типа CMS» для того, чтобы по адресу /about выводился какой-нибудь текст, в 99% случаев достаточно сделать файл about.txt и пихать все туда, если надо запихать больше одного значения («текст и заголовок») — то serialize и вперед (нет, не xml и прочее гавно).
Да и вообще, CMS никому не нужны.
У меня был движок блога, «написанный на файлах» и была даже специальная кнопочка, на которой значилось «no sql». У Болка движок блога, кстати, до сих пор на файлах работает, а ведь уже 21 век на дворе.
С тех пор прошло много времени, остальное отсталое человечество дозрело и движение nosql действительно завелось и стало трендом, похуже mysql.
Я же совершенно случайно и безотносительно ко всяким трендам попробовал mongodb и полюбил.
Пользоваться mongodb надо не из-за производительности, масштабируемости, nosql (забудьте все, что я говорил выше), а только хотя бы потому, что после ее использования внутри остается теплое приятное чувство, что Сделал Всё Правильно.
В mongo можно пихать «документы», при этом документ — это массив. Поднимите руки, что любит массивы так же, как люблю их я? Ага, молодцы, возьмите с полки пирожки.
Что самое смешное — на предыдущем проекте я написал простенькую «оболочку» для mysql, которая позволяет работать с «документом», как с «массивом» (ну, чисто формально оно и сейчас позволяет, после запроса возвращается же массив? А теперь попробуйте изменить в нем одно значение и запихать его обратно, ага).
Документы не обязаны иметь строгую структуру, это называется «schema-less». Не, ну я любил заниматься анальными извращениями и решать, где для столбика в mysql хватит tinyint, а где и вовсе bit(4), но всему есть предел, к тому же после второго раза это уже не так интересно.
Тем те менее, несмотря на то, что нет «обязательных» полей, строить по ним индексы мы все равно можем. А потом искать по ним (впрочем, искать можно и вовсе без индексов, причем иногда более оптимально, чем с ними — когда требуется перебор всей таблицы, например).
Таким образом, «коллекция» в mongo представляет собой просто набор массивов, куда можно свободно писать, свободно модифицировать и свободно делать любые выборки по любому количеству полей, не хуже, чем в mysql.
Кстати, запросы для выборок — тоже массивы. Очень удобно генерировать их автоматически, не надо подставлять «SELECT .... FROM» в нужных местах, просто создал массив — и вперед. То есть, если документ-массив целиком же кинуть в выборку в качестве запроса, то он найдет и вернет самого себя (что логично), если часть документа, напимер, массив user => acerbial, то оно вернет все документы, где user => acerbial.
«Но без join-ов».
В этом — прелесть номер два. Так как пихать можно любые массивы (это называется «Document Store»), половина join-ов отпадает естественным образом.
Например, заметка и комментарии к ней — это один документ, а не 1+N запись в базе данных (где N — количество комментариев).
Учитывая, что максимальный размер документа — 4 мегабайта, и ты не обязан работать с ним целиком, не только нет причин не хранить комментарии отдельно, но это является единственным логичным и правильным способом.
Сразу решается «проблема» удаления текста и удаления комментариев к нему.
Очень просто решаются задачи, типа «закладки пользователя» — они принадлежат, натурально, пользователю.
Ну давайте уже признаем, что в вебе хранятся и выводятся документы — сразу станет легче жить.
Многие мелочи заботливо сделаны «для веба», да и просто — заботливо сделаны. У каждого документа есть автоматически создаваемый уникальный id («аналог» int autoincrement в mysql), о котором не надо заботиться — он просто есть и работает. Более того, когда ты запишешь новый документ в коллекцию, mongo вернет этот id сам, mysql же придется об этом просить отдельно.
Есть capped collection — коллекция, которая обрезает себя сама («хранить 100 последних документов»), идеально для ведения логоподобной ерунды. Есть upsert — «если документ не существует, то создать», это позволяет писать один и тот же код для создания и редактирования. (Что тоже меня всегда бесило в MYSQL — там update и insert это две разные команды).
Можно не только указать, какие поля возвращать («как в mysql»), но и обратное — указать, какие не возвращать.
В результате всех этих мелочей код у меня выходит раза в два меньше (и раза в два медленней, смакую удовольствие) и пока что нет никакой необходимости создавать обертки вокруг mongodb, все стандартные классы делают ровно то, что нужно.
Инъекций, как легко догадаться, тоже не существует в принципе, как можно сделать инъекцию в массив?
Mongo просто очень приятный и покрывает все потребности «домашних веб-движков блогов» лучше, чем это делает mysql.
Скорее всего, он более подходит и для «серьезных, масштабируемых проектов», но в эти дебри мне углубляться не хочется, потому что там все сводится к аргументу «99.99% стартапов никогда не умрут от излишней посещаемости, поэтому не выебывайтесь, и делайте на mysql+php».
Проблема в том, что на mysql просто физически неприятно после того, как попробовал mongo.
Главный минус — Монго пока что мало где стоит, и уж явно не стоит на хостингах за 5 баксов.
Собственно, поэтому и я агитирую — ставьте, пробуйте, требуйте в магазинах города. Так победим.
Остальные «минусы» Монго вытекают из плюсов — ну, знаете, как с девушками: «страшная, но ебливая», и являются не минусами, а «архитектурными решениями».
Например, по умолчанию Монго пишет на диск когда захочет (Mongo writes when it pleases, ага). За счет этого достигается феноменальная скорость работы (проще просто сказать «ага, записал» на очередной запрос, а записать как-нибудь потом) и феноменальное умение проебывать данные за последнюю минуту и портить всю базу, если отрубилось питание (поправимо с помощью --repair, но осадочек остается).
С одной стороны, это все поправимо, никто не запрещает делать запросы с опцией принудительной записи, с другой — в этом и прелесть, за супермегапроизводительность надо чем-то платить.
(Рекомендуемая книга — MongoDB: The Definitive Guide, хотя для начала мануала на сайте хватает «за глаза»).
Гамифицируйся!
Придумали «новый» тренд, называется «gamification».
Вы не поверите — это тренд про добавление в (веб) проекты игровых элементов!!111
Во-первых, это напоминает бессмертное «можно добавить к игре любого жанра элементы RPG, и она хуже не станет».
Во-вторых, как и все тренды, этот существует уже сто лет, но просто «слово появилось». Пока не было слова — не было и тренда, да. Ну действительно, как же без слова-то.
Тренд совершенно безумный, потому что искусство и так имитирует жизнь, любая метафора в так называемых «игровых механиках» пришла из жизни, поэтому тренд, типа «а давайте добавим в вебпроекты побольше кошерных вещей из игр» бессмысленный, так как сводится к «а давайте добавим побольше вещей из жизни».
Ну да, ну да. Давайте.
То есть всяким бонусам-хуёнусам, поощрениям и мотивациям уже тысячи лет, их изобрели вовсе не игровые дизайнеры.
В рунете явной гамификацией впервые занялся Яндекс года три назад, (даже выписал себе по этому поводу именитого геймдизайнера) но всем похуй, прежде всего самому Яндексу.
NoSQL
Чуть было очередной тренд не пропустил.
Я так понимаю, что nosql и вообще key-value это теперь пиздец как модно. Мы же пишем свой твиттер и фейсбук, каждый второй.
Скалабилити, хуё-моё. Надо озаботиться.
Кто работал с сабжем (и с каким), плюсы, минусы, подводные камни?