Все таки, хотелось бы услышать от автора размышления на тему «горизонтального масштабирования», «распределенных систем» и «микросервисов» потому как выбор в сторону дорогущего железа ну прям вообще не очевидный! С пачкой микроинстансов нагрузку можно размазать как угодно, всегда будет возможность «вырасти в 2 раза» по любому показателю, будь это IOPS или трафик! Про всякие хардварные оптимизации вообще можно не трогать, ведь какой-то части проекта нужен быстрый диск, какой-то много оперативы, а какой-то проц, в случае с дорогим железом все части проекта получают всё и это ни разу НЕ оптимально/эффективно/(любое другое слово, которое вы для себя придумаете, чтобы доказать ущербность выбора)
Поиграться в железячки — да, круто! Челендж по типу «а смогу ли я» — тож норм тема! Всегда хотелось иметь и вот я решился — молодец, получилось, снмаем шляпу! Но, блин, «под проект» с 500 чел онлайн? Риали o_O? В бородатом 2008 делали игрульки для ВК-шечки, там VDS в 1000 раз тормознее справлялся при онлайне в 2к юзеров и был не «в полке»! Поэтому, статья, без раскрытия «проекта» всех ставит в ступор! Хотябы без линка, опишите чё ж это там такое-эдакое, что ему такая железяка потенциально может понадобиться?
А еще, в догоночку, а когда на вас первый DdOS прилетит, вы себе тоже железо купите?
Настроил аналогичное железо D-Link DNS-320L, но transmission выжирает проц на 100% и становится недоступен как только кидаю торрент на закачку. Кто-то сталкивался с такой проблемой?
Ок, ваша позиция по поводу prepared statements мне ясна, это конечно следовало ожидать но, явно, до этого, вроде, вы это нигде не написали…
Мы же говорим не только о подходе но и о «Классе для удобной и безопасной работы с MySQL» а из за различия в понимании «удобный» весь диалог…
Еще интересна ваша позиция по поводу «разорванного» sql, который в вашем случае, как я понимаю, будет приводить к
SELECT ?p FROM table ?p WHERE ?p GROUP BY ?p ORDER ?p LIMIT ?p
и само WHERE Это что то вида
?p ?p ?p ?p
или
$previous_where = '1=1';// какое то предустановленное условие
$where = $db->prepare('some_condition AND ?p', $previous_where);
//... 100500 строк логики
$where = $db->prepare('(?p) OR another_condition', $where);
//... 100500 строк логики
$where = $db->prepare('yet_another_condition AND((?p) OR another_condition2)', $where);
да я понимаю что это не одно и то же, и вы понимаете, и в предыдущей статье указали, так почему же в реализации с упором на безопасность вы игнорируете prepared statement?
Они усложняют код, но не дают никакой пользы на практике. Да ещё и затрудняют отладку.
По каждому пункту могу высказать совершенно обратное, поэтому без аргументов это всего лишь слова…
Ну вот вам пример с датами: в базе поле datetime а вы в скрипте оперируете unix_timestamp-ом, при подстановке вам нужно или отформатировать значение локальной переменной или заняться конвертированием на стороне БД…
Ну я предполагаю что вы мне ответите SELECT * FROM table WHERE my_date_field > FROM_UNIXTIME(?i)
Просто как по мне то это несколько некрасиво чтоли… Понятно что все равно это делать придется, вопрос лишь в том «где это делать?» и «делать ли это руками?» Как по мне то с builder-ом проблема решается прощще… Вам же для автоматизации не хватает placeholder-а дат.
P.S.: В общем я про то что с builder-ом код остается читабельным даже если его разорвать до мелочей, в случае с плейсхолдерами код теряет в красоте и я не вижу ни каких преимуществ в таком подходе и собственно веду я к тому что посмотрите поближе на какой нибудь QueryBuilder, например от Zend вы его обязательно полюбите…
$some_id может быть равно 'title'
И, следовательно, являться как именем поля, так и его содержанием.
Так оно же не может, мы же там предполагаем идентификатор, вы же сами написали:
Я составляю SQL запрос, и, разумеется, я знаю, в какое место запроса идут те или иные данные.
Еще момент
Вопроса, «а куда собственно должны быть вставлены данные?» я не понял
Который может предназначаться как для оператора IN, так и для оператора SET
уловили?
В момент вставки данных вам нужно знать а что же надо будет сделать с данными и выбрать для этого соответствующий placeholder, при использовании bulder-ов об этом не приходится думать…
В предыдущей статье вы писали правильные вещи:
Тот же эскейпинг защиту не гарантирует
и рассказали про то чем хорош prepared statement и placeholders, но почему теперь пишете про то что:
prepared statements не нужны. Они усложняют код, но не дают никакой пользы на практике. Да ещё и затрудняют отладку.
По поводу типов: а как же enum, datetime, timestamp etc. Только не говорите что для них вполне подходит ?s и ?i
Конечно же вы правы, просто вас сбили с толку имена стандартных php функций в скобках… Как анализатор будет анализировать типы данных — по заготовленной схеме, извлекать схему БД или как то еще я во внимание не беру. Кроме того это «ожидаемые» типы а я писал о «входящих» типах, тех, которые мы имеем для передачи в запрос. Их соответствие «ожидаемым» и обработка исключений в случае несоответствия — отдельная тема. Важно то, что теряется смысл использовать какой либо другой плейсхолдер кроме "?"
В случае с «построителем» запроса сохраняется контекст вставки данных и многие проблемы с этим связанные не возникают… Кроме того: разбить запрос на кучку строк и после собрать их воедино пускай и плейсхолдерами или работать с методами одного объекта в разных местах? Вот про что я!
Ну например $some_id = '5'; и наш «анализатор» говорит что это строка, в where попадает что то вида «SELECT… WHERE id = ?s» что в итоге приведет к обработке переменной $some_id как строки с которой будут проделаны все «подготовительные» операции перед вставкой… Тоже самое если «анализатор» определит ее как число, просто набор «подготовительных» операций разный…
Передача данных в разное место запроса без «построителя» ставит вопрос «а куда собственно должны быть вставлены данные?» в случае с «построителем» такой вопрос не возникнет.
Какую задачу решает ваш код? В какой предметной области? Какие преимущества в использованном подходе? Вот что бы я хотел услышать…
Каждой задаче — свое решение, но как поведет себя ваш код в запросе на 200 строк? Удобно ли будет оперировать плейсхолдерами говорящими что вот в конкретное место вставляется строковые(числовые и т.п.) данные, но не говорящими откуда приходят данные или что за сущности в них… А это очень важно чтобы ваш код был легко читаемым…
Mysqli, self-made placeholders и в итоге код без prepare statement? В чем соль?
… наличие плейсхолдеров для любого типа данных...
А вот и проблема оптимальности и универсальности, как только вы начнете поддерживать «любой тип данных» код обрастет кучей сложной логики и перестанет быть простым, быстрым и отпимизированным, но пока вы этого не сделаете код не станет универсальным :)
В любом случае успехов вам в ваших исследованиях, надеюсь не остановитесь! Это просто стадия развития проекта такая — когда все вокруг говорят что ты делаешь велосипед. Ясно станет потом…
Не знаю, как по мне то это задача никак не для класса работы с БД, возможно как security прослойка но не больше, по мне — лучше уж использовать всевозможные «построители» sql запросов и передавать в них корректные, обработанные данные тогда и работа с «частями» sql станет прозрачнее чтоли…
Вот такой код мне бы понравился больше…
А вот внутри он может делать всю ту работу которую делает ваш код, потому как обрабатываемых типов то всего: строка, число и «набор». Остальные относятся к деталям реализации… А определить тип данных (is_numeric, is_array etc) и вставить вместо? какой нибудь ?i или ?s не большая проблема.
Поиграться в железячки — да, круто! Челендж по типу «а смогу ли я» — тож норм тема! Всегда хотелось иметь и вот я решился — молодец, получилось, снмаем шляпу! Но, блин, «под проект» с 500 чел онлайн? Риали o_O? В бородатом 2008 делали игрульки для ВК-шечки, там VDS в 1000 раз тормознее справлялся при онлайне в 2к юзеров и был не «в полке»! Поэтому, статья, без раскрытия «проекта» всех ставит в ступор! Хотябы без линка, опишите чё ж это там такое-эдакое, что ему такая железяка потенциально может понадобиться?
А еще, в догоночку, а когда на вас первый DdOS прилетит, вы себе тоже железо купите?
Мы же говорим не только о подходе но и о «Классе для удобной и безопасной работы с MySQL» а из за различия в понимании «удобный» весь диалог…
Еще интересна ваша позиция по поводу «разорванного» sql, который в вашем случае, как я понимаю, будет приводить к и само WHERE Это что то вида или
Вместо:
По каждому пункту могу высказать совершенно обратное, поэтому без аргументов это всего лишь слова…
Ну вот вам пример с датами: в базе поле datetime а вы в скрипте оперируете unix_timestamp-ом, при подстановке вам нужно или отформатировать значение локальной переменной или заняться конвертированием на стороне БД…
Ну я предполагаю что вы мне ответите
SELECT * FROM table WHERE my_date_field > FROM_UNIXTIME(?i)Просто как по мне то это несколько некрасиво чтоли… Понятно что все равно это делать придется, вопрос лишь в том «где это делать?» и «делать ли это руками?» Как по мне то с builder-ом проблема решается прощще… Вам же для автоматизации не хватает placeholder-а дат.
P.S.: В общем я про то что с builder-ом код остается читабельным даже если его разорвать до мелочей, в случае с плейсхолдерами код теряет в красоте и я не вижу ни каких преимуществ в таком подходе и собственно веду я к тому что посмотрите поближе на какой нибудь QueryBuilder, например от Zend вы его обязательно полюбите…
Еще момент
уловили?
В момент вставки данных вам нужно знать а что же надо будет сделать с данными и выбрать для этого соответствующий placeholder, при использовании bulder-ов об этом не приходится думать…
В предыдущей статье вы писали правильные вещи:
и рассказали про то чем хорош prepared statement и placeholders, но почему теперь пишете про то что:
По поводу типов: а как же enum, datetime, timestamp etc. Только не говорите что для них вполне подходит ?s и ?i
В случае с «построителем» запроса сохраняется контекст вставки данных и многие проблемы с этим связанные не возникают… Кроме того: разбить запрос на кучку строк и после собрать их воедино пускай и плейсхолдерами или работать с методами одного объекта в разных местах? Вот про что я!
Передача данных в разное место запроса без «построителя» ставит вопрос «а куда собственно должны быть вставлены данные?» в случае с «построителем» такой вопрос не возникнет.
Какую задачу решает ваш код? В какой предметной области? Какие преимущества в использованном подходе? Вот что бы я хотел услышать…
Каждой задаче — свое решение, но как поведет себя ваш код в запросе на 200 строк? Удобно ли будет оперировать плейсхолдерами говорящими что вот в конкретное место вставляется строковые(числовые и т.п.) данные, но не говорящими откуда приходят данные или что за сущности в них… А это очень важно чтобы ваш код был легко читаемым…
Mysqli, self-made placeholders и в итоге код без prepare statement? В чем соль?
А вот и проблема оптимальности и универсальности, как только вы начнете поддерживать «любой тип данных» код обрастет кучей сложной логики и перестанет быть простым, быстрым и отпимизированным, но пока вы этого не сделаете код не станет универсальным :)
В любом случае успехов вам в ваших исследованиях, надеюсь не остановитесь! Это просто стадия развития проекта такая — когда все вокруг говорят что ты делаешь велосипед. Ясно станет потом…
Вот такой код мне бы понравился больше…
А вот внутри он может делать всю ту работу которую делает ваш код, потому как обрабатываемых типов то всего: строка, число и «набор». Остальные относятся к деталям реализации… А определить тип данных (is_numeric, is_array etc) и вставить вместо? какой нибудь ?i или ?s не большая проблема.