Ответы пользователя по тегу MySQL
  • Обнаружил sql- уязвимый код. Какие возможности? Как воспользоваться?

    papahoolio
    @papahoolio
    Как-то так
    1'where (1)=(select 1 from(select count(*),concat(version(),floor(rand(0)*2))x from information_schema.tables group by x)a)--
    Ответ написан
  • Синхронизация MySQL запросов

    papahoolio
    @papahoolio
    Миграции.

    Идея миграций - вынести создание и изменение структуры бд в программный код. Одно изменение - одна миграция. Миграции имеют порядковый номер и соответственно выполняются друг за другом согласно порядковому номеру, где-то в системе всегда хранится номер миграции, которая была применена последней.

    Главное в миграциях, что после того, как она попала в репозитарий проекта, она изменяться уже не должна! Если нужно отменить изменения уже опубликованной миграции, пишется новая, отменяющая/исправляющая старую.

    Разработчики должны изменения структуры/наполнение бд делать только миграциями.

    Опять же для CodeReview миграции просто отличный инструмент.

    Для PHP
    Например в Yii:
    www.yiiframework.com/doc/guide/1.1/ru/database.mig...

    Как отдельно решение
    https://github.com/ruckus/ruckusing-migrations

    Для Python:
    https://pypi.python.org/pypi/alembic

    bash:
    https://github.com/dwb/dogfish/blob/master/dogfish
    Ответ написан
  • Много параметров у модели: сериализация или отдельная таблица?

    papahoolio
    @papahoolio
    Похоже, что при описании проблемы упущен важный момент, а как эти поля будут использоваться. Нужны ли будут данные из них всегда или только в определенных случаях?

    Давай посмотрим плюсы и минусы решений. Ну как я их вижу.
    Для варианта номер один.
    Плюсы:
    - со стороны PHP легко будет расширить AR
    Минусы:
    - unserialize медлено, есть конечно json и igbinary, но это все равно время
    - если полей "будет становиться всё больше", то в MySQL сериализованые данные нужно будет хранить в TEXT/BINARY поле, если мы говорим о стандартных ENGINE MySQL, то при выборке такие поля в память не загружаются, а читаются с диска, ну ты понимаешь, что дисковые I/O операции дорогие (в случае с InnoDB там может быть лучше ситуация)
    - если у нас случай, когда данные из "неизвестных" полей нам нужны редко, то при таком подходе, либо надо будет рисовать workaround в AR чтобы эти поля не тащить, либо будут данные постоянно пересылаться м/у БД и PHP, плюс в памяти PHP висеть
    - если база разрастется и нужно будет вытащить "неизвестное" поле в поиск/фильтрацию, изменение схемы таблицы потребует времени, вытаскивание данных из сериализованного поля и заполнение нового поля - потребует времени, построение индекса по новому полю - потребует времени. Много данных - много времени, времени простоя сервиса.

    Для варианта два.
    Плюсы:
    - если размер данных в полях лимитирован и залезает в тип VARCHAR, решаем проблему номер два первого способа
    - масштабируемо
    - внедрение поиска/фильтра по полю не повлечет переделывания структуры таблиц
    Минусы:
    - если данные нужны всегда, получится JOIN,если полей с данными будет много, то JOIN будет медленным. Если тип у полей будет TEXT... ну ты понял :)
    - проблему один можно решить кешированием, но реализация на PHP в рамках AR уже станет не самой простой задачей
    - да вообще в рамках AR Yii реализация такого подхода с lazy loading потребует нормального такого понимания, как AR в Yii устроен и где его надо менять, чтобы всем было хорошо

    Правильного варианта, как ты понимаешь нет, нужно взвесить все "за" и "против", понять насколько имеет смысл делать "круто" сейчас и тратить время или можно залезть в technical debt, но быстро запуститься уже завтра.
    Ответ написан
  • Как организовать структуру БД?

    papahoolio
    @papahoolio
    совмещаем решение toster.ru/q/54424#answer_198854 с toster.ru/q/54424#answer_198864 и получаем оптимальную для старта структуру

    т.е. есть таблица лога
    в таблице клиентов есть атрибут со значением текущего тарифа и триггер на insert в таблицу лога, пересчитывающий тариф клиента
    коэффициенты для машин могут быть, могут не быть - зависит от бизнесс-процесов и возможностью изменения их в будущем
    Ответ написан