MR
какая-то непонятная цель перехода. чтобы меньше знаний надо было? тогда не надо переходить
Вначале будете легко и быстро писать код
Потом попадете в ад по производительности если нет многа опыта
Size: a a a
2021 August 25
IA
YP
Если предположим, что ORM полностью покрывает все задачи и нет сложных запросов. То могут быть проблемы?
YP
У меня цели перехода нет, я против
SB
Тогда непонятно зачем вы инкапсулируете запросы в хранимки, если они простые.
c
Обоснование, простите, хиленькое у руководства :)
SU
а как же запас на будущее? когда запросы усложнятся?
ОО
когда запросы усложнятся, ORM тем более не поможет
YP
У нас разные запросы и сложные и простые. Я формулирую свои вопросы, таким образом, что бы получить тот ответ который мне нужен.
SU
об этом и речь. поэтому я тоже не использую orm
VF
Орм не нужна
АС
ORM нужна
вы же хотите из БД получать типизированные объекты, а не поток байт в ответе?
вот Active Record - точно не нужно
Прекрасный пример на тему того, что незнание терминологии приводит к каше в голове. И эти люди тут весь день стебались над "СУБД"...
вы же хотите из БД получать типизированные объекты, а не поток байт в ответе?
вот Active Record - точно не нужно
Прекрасный пример на тему того, что незнание терминологии приводит к каше в голове. И эти люди тут весь день стебались над "СУБД"...
YP
Это уже о другом. Мне понять смогут ли разработчики без углублённых знаний бд и sql решать простые задачи с помощью ORM и не сталкиваться с проблемами
IA
Простые да.
Но чуть сложнее - надо писать руками sql
И схему надо руками пилить
Но чуть сложнее - надо писать руками sql
И схему надо руками пилить
MR
а что не так с active record? оно повсеместно используется
АС
всё не так
АС
концепция данных, знающих о своём способе хранения - лютейший бред, какой только может быть
АС
а еще повсеместно python используется
как новый basic
это же не значит, то он - хороший язык?
как новый basic
это же не значит, то он - хороший язык?
VF
Что за "поток байт"? Обычно в БД есть разные способы получения данных