Comments 22
Простите, а что в вашей статье имеет отношение к проблематике ORM? На мой взгляд вы еще даже уровень модели сущностей и отношений не покинули, до реализации еще шагать и шагать.
Многие не понимают что такое ORM, потому что не могут абстрагироваться от конкретных реализаций универсальных ORM, «почему-то» позволяющих просто отображать лишь очень простые отображения. А ведь ORM это лишь код, позволяющий однозначно соотнести объекты (конкретные!) программы и записи (не менее конкретные!) в RDBMS. Он вовсе не обязан быть универсальным, он вовсе не обязан быть дескриптивно-декларативным, он вовсе не обязан быть отображающим свойство на столбец и наоборот, он вовсе не обязан быть ещё каким-то, кроме как решающим две задачи (и то не обязательно в общем случае): состояние объектов должно однозначно отображаться на БД и наоборот. Реализуем мы скалярное свойство объекта через поле в таблице или через 15 таблиц один-к-одному, а то и многие-ко-многим (но через соглашение типа «на свойство объекта маппится последняя по времени запись, а свойство объекта маппится на последнюю запись с таким же значением или новую, если у последней значение не такое»), а то и вообще через хранимку с хэшем от id объекта конкатенированным с фазой луны, никого кроме разработчика ORM, согласовывающего свои действия с прикладным разработчиком и разработчиком БД волновать не должно.
Эх… этот прекрасный новый мир в котором есть разработчик ORM, прикладной разработчик и разработчик БД… очень часто считается что первого заменит офф. документация, второй есть в наличии (ну как же, код пишет) а третий не нужен, т.к. хватит все той-же офф. документации… да и вобще, зачем тогда ORM?
Поймите, я не свое мнение высказываю, просто сталкиваясь с таким подходом прибываю в шоке. Самый вопиющий подход который используют «прикладные разработчики» я и попытался рассмотреть.
Поймите, я не свое мнение высказываю, просто сталкиваясь с таким подходом прибываю в шоке. Самый вопиющий подход который используют «прикладные разработчики» я и попытался рассмотреть.
Так это ещё лучше в каком-то смысле получается: един в трех лицах и ничто не мешает написать ORM заточенную под задачу и подогнать под неё же схему БД.
Проблема в том что очень часто под специфические задачи пытают использовать универсальные ORM, вместо того чтобы написать свою строго под задачу заточенную.
Проблема в том что очень часто под специфические задачи пытают использовать универсальные ORM, вместо того чтобы написать свою строго под задачу заточенную.
Эмм… я скорее хотел поднять вопрос проблем использования orm программистами не понимающими как в конечном счете данные будут отображены в таблицы. Некоторые считаеют что orm — эта такая магия, используя которую можно просто указать драйвер, описать пару классов и все шоколадно. А проблемы миграции, сериализации, сохранения отображения (структуры) — им чужды.
Это смотря с какой стороны посмотреть. Одна из целей абстрагирования в разработке ПО как раз и заключается в том, что бы особо не думать о том, что находится на нижних уровнях и как именно работает.
Имхо слишком провокационный заголовок. На первый взгляд создаётся впечатление, что вы призываете программистов не учить SQL, хотя без SQL в профессии вообще делать нечего.
ORM имеют множество достоинств, проявляющихся в длительной перспективе. Это прежде всего безопасность запросов (ORM обычно берёт на себя экранирование); потом представление параметров типами данных основного языка, без утомительной конверсии; автоматизация бэкапа и деплоя в условиях навороченных constraints; прозрачные кэширование данных и отложенные запросы; переносимость (если ORM работает с несколькими СУБД)… Что точно не является достоинством ORM − так это абстрагирование от SQL. Это даже скорее недостаток. В гипотетическом случае, когда достоинства ORM не востребованы, вызов SQL будет проще писаться, лучше читаться (SQL использует концепцию литературного программирования, если что) и работать производительней.
Кстати, в вашем случае я бы создал одну таблицу для мужчин, женщин и прочих гендеров-шмендеров, а соотношения many-to-many между ними так же реализовал бы в виде отдельной промежуточной таблицы. Нет никаких проблем в том, чтобы связи между строками одной таблицы задать в другой таблице, но об этом часто забывают. Считайте это пропагандой нетрадиционных отношений. :)
ORM имеют множество достоинств, проявляющихся в длительной перспективе. Это прежде всего безопасность запросов (ORM обычно берёт на себя экранирование); потом представление параметров типами данных основного языка, без утомительной конверсии; автоматизация бэкапа и деплоя в условиях навороченных constraints; прозрачные кэширование данных и отложенные запросы; переносимость (если ORM работает с несколькими СУБД)… Что точно не является достоинством ORM − так это абстрагирование от SQL. Это даже скорее недостаток. В гипотетическом случае, когда достоинства ORM не востребованы, вызов SQL будет проще писаться, лучше читаться (SQL использует концепцию литературного программирования, если что) и работать производительней.
Кстати, в вашем случае я бы создал одну таблицу для мужчин, женщин и прочих гендеров-шмендеров, а соотношения many-to-many между ними так же реализовал бы в виде отдельной промежуточной таблицы. Нет никаких проблем в том, чтобы связи между строками одной таблицы задать в другой таблице, но об этом часто забывают. Считайте это пропагандой нетрадиционных отношений. :)
Да, заголовок, как и содержание, получился очень провакационным… У меня есть подозрение что большинство негатива как раз вызвано формой и сумбурностью материала. Нет, я понимаю, что прописные истины на хабре идут плохо, но это повсеместное засилье «реализаций по оф. документации» которорые сводятся к прочтению примера из 2-х моделей — добивает.
Красота-то какая… Ну, подумаешь, пара лишних джойнов при селекте…
Вы открыли EAV? Работаете в медицине, где предметная область, настолько деревянна и многопризначна, что ужос? Вот не уловил сути. Поток сознания надо обработать и покачественней выдать.
Прошел год как я сменил профессию сетевого администратора на профессию программиста.
Прошу вас. Вернитесь обратно. Право слово всем будет лучше. Если все же не хотите, то мой совет. Прежде чем браться за ORM прочитайте хотя бы это Основы современных баз данных. Хотя цикл лекций написан давно, но актуальности особо он не потерял.
Далее после того когда вы поймете что такое реляционная база данных и научитесь нормально проектировать базы данных, вот только тогда можно взять ORM. ORM является дырявой абстракцией. И если вы хотите чтобы это нормально работало и это можно было использовать, то движение должно быть база данных -> ORM -> объекты. Любые люди которые говорят что мы сейчас объектов наделаем и через ORM их в базу положим и все будет чики-пуки врут. Это работает только для малых объемов данных и малого количество объектов. Любое увеличение данных и или количества объектов, приводит к резкому снижению производительности и большому числу проблем.
в переводе на язык Пушкина означает «Объектно-реляционное отображение»Нѣтъ, «Объектно-реляціонное отображеніе». Языкъ Пушкина имѣлъ на 4 буквы больше, не говоря ужъ объ иныхъ возможностяхъ орѳографіи.
Программисты забывают о первой буковке абравиатуры и пхнут в одну и ту же табличку все! Начиная от свойств объектов, что логично, и, заканчивая foreign key, что никакого отношения к объекту не имеет!
Шта? Или я не совсем понял куда у автора впихивается foreign key или автор имел ввиду чтото другое.
Ведь в ORM на начальном уровне мы описываем Model что в реляционных базах есть таблица, с описанием свойств атрибутов, и конечноже один из атрибутов таблицы/модели будет foreign key.
Ну а потом уже работа с инстансами/объектами конретной модели/таблицы.
Или речь шла не об этом…?
Думаю, не совсем поняли. Автор связи one-to-one впихивает в отдельную таблицу т.е. то что (вероятно) вы обычно делаете для many-to-many связей.
… и конечноже один из атрибутов таблицы/модели будет foreign key.
Ну а потом уже работа с инстансами/объектами конретной модели/таблицы.
Вот об этом я и говорил… :-)
«там все просто! вжик-вжик и побежали» — повсеместная трактовка алгоритма работы с ORM (и как следствие с БД). Многие думают что структура данных не важна, просто пиши код.
Знаете, ORM со своим ООП подходом создает илюзию что форма хранения не важна (мало кто разбирался как в памяти хранятся экземпляры обектов), можно просто делать «new» и все будет хорошо. Мое мнение: ЭТО НЕ ТАК!
Так тоже самое бывает и ДБДшников некоторые из которых не знают языков програмирования и ООП.
И создают таблицы с foreign key_ями не вынося релейшены в отдельну таблицу.
Ну окей. Вы имели ввиду что ОРМ ваще облегчает писание кода без релейшн таблиц не вспоминая о подобной возможности.
И создают таблицы с foreign key_ями не вынося релейшены в отдельну таблицу.
Ну окей. Вы имели ввиду что ОРМ ваще облегчает писание кода без релейшн таблиц не вспоминая о подобной возможности.
Знаете, ORM со своим ООП подходом создает илюзию что форма хранения не важна (мало кто разбирался как в памяти хранятся экземпляры обектов), можно просто делать «new» и все будет хорошо. Мое мнение: ЭТО НЕ ТАК!
Просто вы судите об ORM по тем примерам, с которыми вы знакомы.
В реальности, задача ORM в том, чтобы форма хранения действительно не имела значения (это называется «абстракция от хранилища»), вопрос в том, насколько успешно эта задача выполняется (и выполнима).
Это, конечно, не так. Но ООП модель и схема хранения её состояния в БД отношение друг к другу имею весьма посредственное. Задача ORM в том и состоит, чтобы однозначно связать их. И эти связи вовсе не ограничиваются тупым «класс <-> таблица, объект <-> строка, поле <-> колонка». Скажем, один объект может записан в паре таблиц или наоборот — одна запись одной таблицы маппиться на несколько объектов.
Для каждого пола желательно (но не принципиально) иметь свою табличку
Как раз это противоречит объектной модели.
Sign up to leave a comment.
ORM или как забыть о проектировании БД