Здравствуйте, Titus, Вы писали:
R>>"Чистые" ДБА-специалисты как бы денег не меньше программистов себе требуют T>1) database administrator — не программист. T>2) Плохо тот программист, кто не знает ЯМД.
Сорян.
Судя по ответам, ты себе здесь бенефис устроил. Факт, тебе абсолютно не интерсны плюсы и минусы ОРМ.
Продолжайте без меня.
Здравствуйте, Titus, Вы писали:
T>А еще 5000 таблиц в БД, где с точки зрения 3НФ достаточно 50 таблиц. T>Жуткие противоречия в данных, двойной/тройной ввод пользователей и прочие прелести паттерна "лебедь рак и щука".
Здравствуйте, takTak, Вы писали:
T>а зачем тебе это надо знать?
Я так подумал, и понял, что изначально задал вопрос недостаточно точно, хотя, судя по ответам, большинством респондентов был правильно понят.
ORM (Object Relational Mapping, т.е. карта между объектами приложения и объектами БД), конечно же, я использовал и использую. Причем, в ярко выраженной форме я это начал делать довольно давно, после того как познакомился, осознал и принял на вооружение паттерн MVC. Буква M просто создана для этого мэппинга.
Но именно тогда, немного поиграв с Entity Framework, не осознал преимуществ и не принял на вооружение это ORM решение. У меня нет задачи «обеспечить работу с данными в терминах классов, а не таблиц», нет задачи «избавиться от необходимости писать SQL-код для взаимодействия в СУБД». Я считаю, что язык SQL идеально подходит для работы с реляционными БД, его синтаксис оттачивался десятилетиями.
Т.е. ORM я использую, но это 100% hand made, без каких-то ORM библиотек.
В связи с недавними событиями, о которых я писал выше, захотел я еще раз провалидировать: правильный ли вывод о бесполезности ORM сделал много лет назад.
В нашей жизни есть много инструментов, которые нужны одним, и не нужны другим: очки нужны близоруким и не нужны людям со 100% зрением, костыли нужны тем, кто испытывает временные трудности с ногами и не нужны тем, кто таких трудностей не испытывает. Возможно, что и ORM нужен людям с ограниченными в чем-то возможностями.
В идеале, лучшим ответом в этом топике был бы такой: вот смотри, есть задача такая-то. Без ORM библиотеки она решается за N часов, с использованием ORM библиотеки она решается за M часов. Причем M<N в K раз.
Пока была только одна попытка такого ответа, и по моим меркам M оказалась, как минимум, не меньше, чем N.
Здравствуйте, Somescout, Вы писали:
S>Бред. Спорить с дураком — всё равно, что играть в шахматы с голубем. Он раскидает фигуры, нагадит на доску и улетит всем рассказывать, как он тебя уделал.
В принципе, для того, чтобы сказать всем, что ты меня уделал — очень сильный, развернутый, а главное, универсальный аргумент
Здравствуйте, Titus, Вы писали:
T>В принципе, для того, чтобы сказать всем, что ты меня уделал — очень сильный, развернутый, а главное, универсальный аргумент
Это просто подпись, но если хочется к ней придраться — вперёд. Но то что ORM автоматически "раздувает в 10 (пардон, в 100) раз количество таблиц" бредом от этого быть не перестанет.
Здравствуйте, Titus, Вы писали:
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!"
bnk>>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде. T>Вот бы где вменяемый пруф найти...
то есть фактов наличия и использования этих самых ORM тебе недостаточно в качестве пруфов?
T>Пока была только одна попытка такого ответа, и по моим меркам M оказалась, как минимум, не меньше, чем N.
ну ты же не можешь прямо из программы посредством какого-то там вызова API производить операции в реляционных базах данных, т.е. сам язык SQL — не самое идеальное инженерное решение, тем более, что ты сам сказал: ты используешь написанный тобой лично на коленке мэппинг
подсчитай время на его создание, подумай о том, сколько разных сценариев использования этого мэппинга на свете может быть, да просто выложи своё решение, раз ты считаешь, что оно вполне себе самодостаточное на gitHub, и ты увидишь, что даже какой-нибудь Dapper, скорее всего , ушёл гораздо дальше твоего решения в простоте использования и т.д. просто в силу того того, что времени на него было потрачено в тысячи раз больше, миллионы пользователей протестировали почти все уголки и возможные баги, т.е. им или тем же EF просто банальнo проще и безопаснее пользоваться
scf>>- низкие требования к квалификации программистов T>Вот тут как раз и вопрос: если ты высококвалифицированный программист, что тебе даст ORM?
Очевидно же: команда не таких высококлассных специалистов как ты, которой ты управляешь, все-равно пишет высококлассные приложения БД, даже не догадываясь что такое LEFT RIGHT OUTER JOIN
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Для маппинга, и только. Ни один орм не умеет оптимально генерировать сложные запросы. А читать эти сложные запросы — проще повеситьсяподсмотреть в профайлере. Максимум что можно — написать выборку с where.
А без маппинга много ручной работы.
Здравствуйте, Muxa, Вы писали:
bnk>>>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде. T>>Вот бы где вменяемый пруф найти... M>то есть фактов наличия и использования этих самых ORM тебе недостаточно в качестве пруфов?
Именно так. "Все так делают" — для меня не аргумент.
Здравствуйте, Somescout, Вы писали:
S>"ORM автоматически "раздувает в 10 (пардон, в 100) раз количество таблиц"
Ты эту цитату прочитал где или сам придумал?
Здравствуйте, takTak, Вы писали:
T>, и ты увидишь, что даже какой-нибудь Dapper, скорее всего , ушёл гораздо дальше твоего решения в простоте использования и т.д.
Собственные эксперименты проведены давно и выводы сделаны. Возможно, эксперименты были некорректны. Так бывает иногда.
Нужен пруфлинк на корректный эксперимент.
Здравствуйте, Cyberax, Вы писали:
C>Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!"
Ба, кровожадный активист диванных войск из политического флейма к нам пожаловал.
Ты хоть знаешь, чем отличается DBA от программиста?
А так сообщу, из моей практики, что без корпоративного стандарта оформления кода любой программист наследник называет своего предшественника говнокодером.
потом уходит он, и его наследник называет говнокодерем уже его. Как в анекдоте.
-А кто вам дом строил ?
-Да пидорасы
— В смысле?
-Залили фундамент, пришли каменщики стены класть и спрашивают а что за пидорасы вам фундамент заливали? после них пришли штукатуры и первым делом спросили а что за пидорасы стены ложили? потом пришли обойщики спросили а что за пидорасы штукатурили?
И так во всём. Вот и получается что дом строили одни пидорасы.
T>>, и ты увидишь, что даже какой-нибудь Dapper, скорее всего , ушёл гораздо дальше твоего решения в простоте использования и т.д.
T>Собственные эксперименты проведены давно и выводы сделаны. Возможно, эксперименты были некорректны. Так бывает иногда. T>Нужен пруфлинк на корректный эксперимент.
всё правильно, проверка на практике- критерий истины,
я сам с проблемами с производительностью EF не сталкивался, но слышал мнение тех,кто выжимает каждую наносекунду:
да, работа через DataReader- самая быстрая, но и если взять мэппер попроще, типа Dapper — то тоже вполне проканывает даже для наносекундников, зато руками ужасов нашего маленького городка () => ExecuteScalar() == DBNull.Value ? 0 : (double)command.ExecuteScalar() писать не надо,
хотя буквально на днях я таким вот ручным "мэппингом" занимался: просто надо было для трёх таблиц DAL написать, ну я и написал, без всякого EF, но было бы таблиц 7 или больше, я бы такой ерундой не страдал бы, конечно
выложи своё чудо-решение в GitHub, которое так же удобно и комфортно, как Dapper, кто-нибудь даже туда заглянет и скажет чего путное, хотя я сомневаюсь, что там что-то путное и полезное будет, я уже много всего такого повидал, и самописные Wrappers вокруг ADO.Recordset & ADO.Template в Spring.NET & EF & etc.
Здравствуйте, namespace, Вы писали:
T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>Для маппинга, и только.
Ну вот здесь, я, пожалуй, соглашусь. Во всяком случае, давно сделал себе небольшую генерилку классов из из БД.
Кстати, не я один такой. Пример такой генерилки, можно найти в интернетах, здесь, например https://stackoverflow.com/questions/5873170/generate-class-from-database-table
Обратите внимание на размер сорс кода этого "ORM" — 59 строчек.
Но это принцип, прямо противоположный принципу "Code First".
Здравствуйте, Titus, Вы писали:
C>>Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!" T>Ба, кровожадный активист диванных войск из политического флейма к нам пожаловал. T>Ты хоть знаешь, чем отличается DBA от программиста?
Да, знаю. DBA дожидается пенсии и сидит, корчя вид, что он занимается очень мудрыми вещами, крутя очередные настройки tablespace в очередном копролите от Оракла.
Здравствуйте, Cyberax, Вы писали:
C>Поубивал бы этих "программистов СУБД", после них остаётся самое неподдерживаемое гуано в мире. Вида "смотрите какой я крутой DBA и какие у меня крутые запросы!!!"
Справедливости ради, уровень дбашников повыше уровня вебщиков будет. Ну и запросы они ускоряют только в путь в несколько раз и на порядки не только путём покупки 96 Гб ОЗУ на сервер
