История изменений
Исправление no-such-file, (текущая версия) :
Попробую угадать - количество «написанного нами» кода в твоих проектах не превышает 10 MB на проект
Не угадал.
прямые SQL запросы в базу - дорогой в ад
Дорогой ад, это когда на ORM пытаются закостылять INSERT ... SELECT ... ON DUPLICATE KEY UPDATE перебирая объекты в цикле и т.п. вещи. Ну а простые запросы на то и простые, что они просты всегда, хоть ORM у тебя, хоть нет. Все те «удобства и простота» выборки и сохранения данных никак с ORM не связаны. Они вполне доступны без всяких ORM.
ассоциативные массивы становится проклятием, а дата объекты и PHP 7 подсказки типов - очень хорошим, элегантным решением
Решением чего? Какой проблемы? Это напротив, только создаёт проблемы когда нужно использовать обобщённые алгоритмы. Т.е. тебе нужно либо писать обёртки, которые принимают нужный тип сущности (класс объекта), либо не указывать тип, а внутри перебирать свойства объекта с помощью рефлексии, по сути работая с объектом, как с массивом свойств. Ну и ради чего было городить весь этот огород? Схему данных, можно держать отдельно, если она нужна. Совсем не обязательно использовать для этого объект. В компилируемых языках (или близких к таковым по скорости) использование языковых средств (классов) для связывания схемы с данными даёт высокую скорость работы. Но мы то про скриптоту говорим, здесь это ничего не даёт кроме ненужного геморроя.
Исходная версия no-such-file, :
Попробую угадать - количество «написанного нами» кода в твоих проектах не превышает 10 MB на проект
Не угадал.
прямые SQL запросы в базу - дорогой в ад
Дорогой ад, это когда на ORM пытаются закостылять INSERT ... SELECT ... ON KEY DUPLICATE перебирая объекты в цикле и т.п. вещи. Ну а простые запросы на то и простые, что они просты всегда, хоть ORM у тебя, хоть нет. Все те «удобства и простота» выборки и сохранения данных никак с ORM не связаны. Они вполне доступны без всяких ORM.
ассоциативные массивы становится проклятием, а дата объекты и PHP 7 подсказки типов - очень хорошим, элегантным решением
Решением чего? Какой проблемы? Это напротив, только создаёт проблемы когда нужно использовать обобщённые алгоритмы. Т.е. тебе нужно либо писать обёртки, которые принимают нужный тип сущности (класс объекта), либо не указывать тип, а внутри перебирать свойства объекта с помощью рефлексии, по сути работая с объектом, как с массивом свойств. Ну и ради чего было городить весь этот огород? Схему данных, можно держать отдельно, если она нужна. Совсем не обязательно использовать для этого объект. В компилируемых языках (или близких к таковым по скорости) использование языковых средств (классов) для связывания схемы с данными даёт высокую скорость работы. Но мы то про скриптоту говорим, здесь это ничего не даёт кроме ненужного геморроя.