После знакомства с mongoDB появилось желание избавиться в своем ORM от инсталятора создающего структуру БД.
Идея состоит в том, чтобы отлавливать когда драйвер ругается на то, что нет у нас таблицы, и создавать таблицу, если не хватает колонки — создавать колонку.
Проблема типизации решена — при чтении в любом случае у нас в поле NULL будет, раз еще не было записи, а при записи у нас есть тип данных (не тип переменной, а именно тип поля включая set и enum, ибо внутри модуля структура данных типизирована.
Итак вопрос — как вы считаете насколько это криво?
Второй вопрос — подводные камни есть?
Как показывает практика многие проходили через идею выводить страницы подменив вывод 404-ошибки.
Недостаток очевиден — нет индексации ибо для поисковика это 404, и загаженный лог ошибок.
Нет ли здесь подобных подводных камней?
ПЫСЫ: Задача рассматривается в контексте php поскольку если уж я ставлю к примеру Питон, то легко поставлю рядом noSQL какой-то с shemaless и не буду изобретать велосипед. Уточнение ибо может есть какие-то нюансы в реализации.
UPD: Интересует в первую очередь ваше мнение о подходе а не готовые решения. Т.е. ОК/плохо, или там «лучше сделай вот так-вот», готовые решения конечно интересны, но разбирать чужой большой движок чтобы понять как он устроен это не так просто… Спасибо :)
Это будет быдлокод. В лучших традициях жителей теплой Индии. А добавление поля в большую таблицу вообще может занять часы, так что ваш скрипт бодро отвалится по таймауту. Но даже если бы оно делалось мгновенно, это был бы быдлокод.
Хотите schemaless? Просто делаете одну таблицу entities с 3 полями: id, type, blob (в blob сваливаете JSON версию объекта). Но вообще, schemaless — крайне дурацкая идея. БД предлагает дополнительный уровень проверки и организации данных, а ленящиеся изучить язык SQL кажем так, юные программисты, кричат, что им этот SQL не нужен.
Естественно, предложить нормальную альтернативу проверенным надежным решениями никто не может, а монго выглядит как примитивный Key Value storage с яваскриптом для игроделов (ибо эти товарищи даже SQL осилить не смогли). Все серьезные организации используют SQL.
Добавление поля в боевую таблицу с кучей данных да еще и в неприспособленных для этого базах (mongo тот же даже не понял бы проблемы) конечно же делать не стоит. Но в таких ситуациях когда это может занять часы это продумывается заранее…
Ваши утверждения про noSQL имеют очень небольшую долю здравого смысла, и очень много иллюзий, потому что мало знакомы с их идеологией. Я раньше почти так-же рассуждал. Ну только без крайностей конечно… Но познакомившись с идеологией понял что оно того стоит.
Join это чтение.
Если нехватает, то и фиг с ним… грубо говоря NULL.
А при записи все равно будет так или иначе указано в какую таблицу писать. Там и поймаем.
Ну это уже проблема выбора шаред хостинга. Обычно она решаема. На одном их проектов проблема отсутствия Mongo решилась письмом хостеру, который любезно поставил его нам. Но вообще я предпочитаю VDS-ки.
По поводу отсутствия InnoDB — давно таких не встречал…
Это проблема популярности скрипта в первую очередь.
Скрипты которые слишком требовательны — не слишком популярны.
Если писать что оптимально такое-то окружение, но мы стерпим и такое, то это уже получше…
Ну у меня есть схема в скрипте, но она чуть более гибкая…
Меня интересует именно этап установки. Идея в том, чтобы оставлять структуру там, где ей и место, т.е. в каждом конкретном модуле и т.п… Чисто необходимость создавать структуру заранее вызывает необходимость держать структуру в одном и том же месте… плюс как-то отмечать какое из описаний приоритетнее (в некоторых модулях одно и тоже поле может быть скажем строка, а в другом месте это поле с фиксированными вариантами выбора, случай редкий но возможный).
А так — в момент обращения уже известна структура. Да и модули которые реально не используются — не будут плодить под себя таблицы… Альтернативный, более правильный вариант — проверять наличие нужных таблиц и их структуру ДО запроса…
Такое решение было бы хорошим для питона, ибо там скрипт запускается целиком, а не для каждой страницы, но неприемлемо для пхп, где каждый запрос отдельно обрабатывается… нет, можно сохранять состояния, но где? На диске? Лишние права, лишние риски… В сессии? Тоже криво… вот и думаю. Самому не нравится идея использования ошибок не по назначению, но… Сейчас склоняюсь к компромису — первым запросом делать список таблиц у базы, и уже исходя из него делать создание или несоздание структуры базы при записи или возврат пустого ответа при чтении… А уже несоответствие структуры отрабатывать как workarraund. По идее таких случаев быть не должно или быть очень редко, и тут уже исключение/ошибка уместны…
Простой
