LINUX.ORG.RU

История изменений

Исправление ThisNameWasFree, (текущая версия) :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (аля statement из PDO на стороне сервера).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами] с десятком методов для работы через IDE с автодополнением и прочими плюшками)
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных для MariaDB/MySQL.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы если, конечно, вас не укололо докинуть ещё анализатор связей по внешним ключам), но вместо тупого набивание однотипных SQL'ей для чтения\вставки очередной строки изо дня в день каждую неделю можно сразу работать с данными, экономя собственное время и нервы.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (аля statement из PDO на стороне сервера).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных для MariaDB/MySQL.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы если, конечно, вас не укололо докинуть ещё анализатор связей по внешним ключам), но вместо тупого набивание однотипных SQL'ей для чтения\вставки очередной строки изо дня в день каждую неделю можно сразу работать с данными, экономя собственное время и нервы.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (аля statement из PDO на стороне сервера).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных для MariaDB/MySQL.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей для чтения\вставки очередной строки изо дня в день каждую неделю можно сразу работать с данными, экономя собственное время и нервы.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (аля statement из PDO на стороне сервера).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных для MariaDB/MySQL.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (аля statement из PDO на стороне сервера).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (аля statement из PDO на стороне сервера).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц (ну не делать же каждый раз SHOW COLUMNS для каждого запроса?).
  • 5. Поддержка почти всех возможных типов данных.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (аля statement из PDO на стороне сервера).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты самопальную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (эмуляция).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить) зайчатки ORM в проект. На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты замечательную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (эмуляция).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить). На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты замечательную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (эмуляция).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исправление ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить). На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты замечательную ORM на базе драйвера mysqli, которая умеет следующее:

  • 1. Полное экранирование входных данных (эмуляция).
  • 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами])
  • 3. Полный CRUD и немножно больше (индексы и прочее).
  • 4. Кэш анализатора структуры таблиц.
  • 5. Поддержка почти всех возможных типов данных.

    Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

    Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.

Исходная версия ThisNameWasFree, :

Во-первых, не нужно быть голословным и писать шаблонные отмазки. Во-вторых, за все ORM не отвечаю, но конкретно то, с чем имею дело: три года назад умудрился попасть в сопровождение медицинских журналов с офисом в Майами, где околачиваюсь до сих пор, ковыряя десятилетные сорцы и добавляя новую хрень на старое уродство. Один из бывших разрабов, родом из Израиля, перечитал Мартина Фаулера и впёр на основе стратегий Active Record (это байан) и Query Builder (а вот это рекомендую погуглить). На текущий момент я реализовал с нуля идеи этого разраба и впёр в рабочие проекты замечательную ORM на базе драйвера mysqli, которая умеет следующее: 1. Полное экранирование входных данных (эмуляция). 2. Автогенерация кода на основе существующей таблицы (в сорцах на таблицу, к примеру, users, появляется классы user [Active Record / работа с одним объектом] и users [Query Builder / работа с одним|несколькими объектами]) 3. Полный CRUD и немножно больше (индексы и прочее). 4. Кэш анализатора структуры таблиц. 5. Поддержка почти всех возможных типов данных.

Всё это требует для своей работы всего один запрос структуры таблицы (SHOW COLUMNS) единожды для каждой таблицы, которая участвует в запросах к СУБД.

Дополнительная нагрузка на СУБД минимальна (SHOW COLUMNS требует совсем смешные ресурсы), но вместо тупого набивание однотипных SQL'ей изо дня в день можно сразу работать с данными, экономя собственное время.