___>>>И это вобще-то ни мега-запрос, как тут уже сказали, запрос прост... Для тех кто в теме.
E__>>Он может и прост, но выглядит довольно монструозно. А это само по себе плохо. Насколько я понимаю, linq создавался в том числе и для того, чтобы запросы выглядели не столь монстряче.
HL>Может это от того, что вы просто не знаете t-sql?
Нет, это от того, что вы не знаете ничего кроме t-sql (да и t-sql знаете ли Вы t-sql?).
HL>А то можно и про какой-нибудь (условно) итальйнский (испанский, венгерский) язык сказать, что выглядит монстуозно, какие-то буковки непонятные и слова неизвестные.
HL>Те кто в теме запрос понимают за 30 секунд.
А что так долго-то? 30 мс не больше. Подумаешь, запрос на 5 страниц со множеством вложенных подзапросов, на который явно угробили десятки человеко-часов.
Я так понял, что "очень просто сменить СУБД" для вас — это переложить все проблемы на "другого парня", который у вас фигурирует под кличкой "dba". Да, при мало-мальски грамотном дизайне приложение должно быть изолировано от хранилища, и, соответственно, смена последнего не должна приводить к изменению кода приложения. Но каким образом из этого утверждения делается вывод, что сменить СУБД легко?
Явно в проекте с базой на 70 млн. сущностей запросы ОРМ не стоит позволять генерить, и объемы кода в итоге, которые необходимо переносить, немаленькие. А сам апликейшин при нормальном дизайне не должен зависеть от базы, вообще независимо от того, ОРМ у вас там или не ОРМ.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я так понял, что "очень просто сменить СУБД" для вас — это переложить все проблемы на "другого парня", который у вас фигурирует под кличкой "dba".
Вы ничего не путаете? Вы представляете сколько работы будет у dba, если придется не только схему чуть поправить, но и переписать всю тьму кода с tsql на pl/sql?
Как раз в нашем случае dba получает минимум головной боли, т.к. БД выступает в роли простого хранилища данных, а все бизнес логика в дотнет клиенте.
ВВ>Да, при мало-мальски грамотном дизайне приложение должно быть изолировано от хранилища, и, соответственно, смена последнего не должна приводить к изменению кода приложения. Но каким образом из этого утверждения делается вывод, что сменить СУБД легко?
Вы внимательно читали? Г-н iHateLogins предлагал всю бизнес логику запихнуть в хранимки на tsql или pl/sql, а дотнет клиент использовать в качестве непонятно чего ("прослойка" или как он там выразился...).
ВВ>Явно в проекте с базой на 70 млн. сущностей запросы ОРМ не стоит позволять генерить,
С какой это радости? ВВ>и объемы кода в итоге, которые необходимо переносить, немаленькие. А сам апликейшин при нормальном дизайне не должен зависеть от базы, вообще независимо от того, ОРМ у вас там или не ОРМ.
Еще раз ЧИТАЙТЕ внимательно.
Здравствуйте, criosray, Вы писали:
ВВ>>Я так понял, что "очень просто сменить СУБД" для вас — это переложить все проблемы на "другого парня", который у вас фигурирует под кличкой "dba". C>Вы ничего не путаете? Вы представляете сколько работы будет у dba, если придется не только схему чуть поправить, но и переписать всю тьму кода с tsql на pl/sql? C>Как раз в нашем случае dba получает минимум головной боли, т.к. БД выступает в роли простого хранилища данных, а все бизнес логика в дотнет клиенте.
У вас видимо "тьма кода с tsql" ассоциируется исключительно с бизнес-логикой. Сочувствую, ибо это однозначно говорит о качестве ваших проектов.
ВВ>>Явно в проекте с базой на 70 млн. сущностей запросы ОРМ не стоит позволять генерить, C>С какой это радости?
А, ну вы видимо считаете, что всегда можно довериться тому говну, которое генерит NHibernate, а DBA у вас будет тупо таблички перерисовывать. Такой способ бесспорно рулит, если три человека с приложением работают.
Тут и правда без разницы — Оракл или Сиквел сервер.
Обычно вообще-то переход, скажем, на 10g превращается в масштабный и сложный проект и вовсе не потому, что там "бизнес-логика" в базе.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Я так понял, что "очень просто сменить СУБД" для вас — это переложить все проблемы на "другого парня", который у вас фигурирует под кличкой "dba". C>>Вы ничего не путаете? Вы представляете сколько работы будет у dba, если придется не только схему чуть поправить, но и переписать всю тьму кода с tsql на pl/sql? C>>Как раз в нашем случае dba получает минимум головной боли, т.к. БД выступает в роли простого хранилища данных, а все бизнес логика в дотнет клиенте.
ВВ>У вас видимо "тьма кода с tsql" ассоциируется исключительно с бизнес-логикой. Сочувствую, ибо это однозначно говорит о качестве ваших проектов.
Скорее это однозначно говорит о Вашем полном непонимании предмета спора.
ВВ>>>Явно в проекте с базой на 70 млн. сущностей запросы ОРМ не стоит позволять генерить, C>>С какой это радости?
ВВ>А, ну вы видимо считаете, что всегда можно довериться тому говну, которое генерит NHibernate,
Считаете Вы при чем не верно. А я знаю.
ВВ>Обычно вообще-то переход, скажем, на 10g превращается в масштабный и сложный проект и вовсе не потому, что там "бизнес-логика" в базе.
Бизнес логика в базе это одна из основных сложностей перевода проекта с одной СУБД на другую. Вот когда сами попробуете — узнаете.
Здравствуйте, criosray, Вы писали:
ВВ>>А, ну вы видимо считаете, что всегда можно довериться тому говну, которое генерит NHibernate, C>Считаете Вы при чем не верно. А я знаю.
Значит, плохо знаете.
ВВ>>Обычно вообще-то переход, скажем, на 10g превращается в масштабный и сложный проект и вовсе не потому, что там "бизнес-логика" в базе. C>Бизнес логика в базе это одна из основных сложностей перевода проекта с одной СУБД на другую. Вот когда сами попробуете — узнаете.
Попробую что?
Давай-те как посмотрим ваши посты:
— используем возможности СУБД на 20%
— проблем с производительностью нет
— переходим с Сиквел сервера на Оракл, ибо так хочет клиент
Да, и еще:
— 70 млн сущностей
— генерим запросы с помощью NHibernate
Это вот это я должен попробовать?
И вы все это описываете как хоть какой-то мало-мальски полезный опыт? Вы представляете, сколько лицензия на Оракл стоит? Клиент деньги отмывает? Или клиент — это дядя Ваня, который новый диск на горбушке купил?
Советую вам не судить о сложностях перехода с одной СУБД на другую на основе таких проектов.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Явно в проекте с базой на 70 млн. сущностей запросы ОРМ не стоит позволять генерить
Ага, и писать все на ассемблере.
ВВ>А сам апликейшин при нормальном дизайне не должен зависеть от базы, вообще независимо от того, ОРМ у вас там или не ОРМ.
И достигнуть этого можно двумя способами.
1)Перенести всю BL на SQL, что практически смертельно в случае смены БД, так как придется перекраивать кучу кода.
2)Использовать правильные инструменты для работы с БД, которые позволяют BL абстрагировать от хранилища, тогда и смена БД пройдет гладко.
ВВ>И вы все это описываете как хоть какой-то мало-мальски полезный опыт? Вы представляете, сколько лицензия на Оракл стоит? Клиент деньги отмывает? Или клиент — это дядя Ваня, который новый диск на горбушке купил?
Здравствуйте, gandjustas, Вы писали:
ВВ>>Явно в проекте с базой на 70 млн. сущностей запросы ОРМ не стоит позволять генерить G>Ага, и писать все на ассемблере.
Добро пожаловать в реальный мир, здесь иногда приходится писать запросы ручками.
ВВ>>А сам апликейшин при нормальном дизайне не должен зависеть от базы, вообще независимо от того, ОРМ у вас там или не ОРМ. G>И достигнуть этого можно двумя способами. G>1)Перенести всю BL на SQL, что практически смертельно в случае смены БД, так как придется перекраивать кучу кода. G>2)Использовать правильные инструменты для работы с БД, которые позволяют BL абстрагировать от хранилища, тогда и смена БД пройдет гладко.
Для тех в танке повторяю — вынесение BL из БД вовсе не означает "легкости смены СУБД", если, конечно же, речь не идет о хоум-пейджах.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, gandjustas, Вы писали:
ВВ>>>Явно в проекте с базой на 70 млн. сущностей запросы ОРМ не стоит позволять генерить G>>Ага, и писать все на ассемблере.
ВВ>Добро пожаловать в реальный мир, здесь иногда приходится писать запросы ручками.
Только когда надо использовать возможности, не поддерживаемые высокоуровневыми средствами.
ВВ>>>А сам апликейшин при нормальном дизайне не должен зависеть от базы, вообще независимо от того, ОРМ у вас там или не ОРМ. G>>И достигнуть этого можно двумя способами. G>>1)Перенести всю BL на SQL, что практически смертельно в случае смены БД, так как придется перекраивать кучу кода. G>>2)Использовать правильные инструменты для работы с БД, которые позволяют BL абстрагировать от хранилища, тогда и смена БД пройдет гладко.
ВВ>Для тех в танке повторяю — вынесение BL из БД вовсе не означает "легкости смены СУБД", если, конечно же, речь не идет о хоум-пейджах.
Еще раз: главное абстрагировать BL от хранилища.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Обычно вообще-то переход, скажем, на 10g превращается в масштабный и сложный проект и вовсе не потому, что там "бизнес-логика" в базе.
Здравствуйте, _d_m_, Вы писали:
___>СУБД — да это определяется сразу. А вот перекидывать с одной СУБД на другую — тот еще гемор — заказчик посылается в лес.
Интересный подход однако, посылать заказчика. Жалко в ЖКХ где работает мой отец, об этом не знали. А то MSSQL выдохся и перешли на Оракл.
Здравствуйте, Воронков Василий, Вы писали:
G>>И достигнуть этого можно двумя способами. G>>1)Перенести всю BL на SQL, что практически смертельно в случае смены БД, так как придется перекраивать кучу кода. G>>2)Использовать правильные инструменты для работы с БД, которые позволяют BL абстрагировать от хранилища, тогда и смена БД пройдет гладко.
ВВ>Для тех в танке повторяю — вынесение BL из БД вовсе не означает "легкости смены СУБД", если, конечно же, речь не идет о хоум-пейджах.
ВВ>>Для тех в танке повторяю — вынесение BL из БД вовсе не означает "легкости смены СУБД", если, конечно же, речь не идет о хоум-пейджах.
I>Не спорь с ним, он сикп освоил
При чем, что очень похоже, по уровню достаточном только для "хоум пейдж"...
HL>>>>И уж поверьте, сервер не лезет в таблицы с метаданными для одинаковых запросов, там всё довольно хорошо кэшируется. C>>>За каждый промах кеша Вам придется платить. Вот и все.
HL>>Какой промах? План для "select *" ляжет в кэш планов и будет использован для всех аналогичных запросов. После этого Metadata lookup-а не будет. C>До того, как он ляжет в кеш планов и случится промах. Кроме того, кеш планов имеет такое ствойство как expiration date.
Промах случится для любого запроса, которого нет в кэше, будь это "select *" или "select список полей"
HL>>Даже для запросов, для которых плана нет, разница в "select *" и "select список полей" практически отсутствует, потому что и там и там будет просмотр метаданных и кучи еще чего. C>Продолжайте в это верить. А лучше почитайте статьи и не пишите больше глупостей.
Дальше читать не стал, бредом не увлекаюсь. Надеюсь вам не нужно доказывать, что это бред и в очередной раз приводить стоимость запросов с "select *", которые не приводят к table scan-у?
Здравствуйте, criosray, Вы писали:
___>>>>И это вобще-то ни мега-запрос, как тут уже сказали, запрос прост... Для тех кто в теме.
E__>>>Он может и прост, но выглядит довольно монструозно. А это само по себе плохо. Насколько я понимаю, linq создавался в том числе и для того, чтобы запросы выглядели не столь монстряче.
HL>>Может это от того, что вы просто не знаете t-sql? C>Нет, это от того, что вы не знаете ничего кроме t-sql (да и t-sql знаете ли Вы t-sql?).
Я вообще-то программирую на C# уже 8 лет, более того, сейчас занимаюсь этим в буржуинии (где всё-таки уровень повыше, чем в России).
HL>>А то можно и про какой-нибудь (условно) итальйнский (испанский, венгерский) язык сказать, что выглядит монстуозно, какие-то буковки непонятные и слова неизвестные.
HL>>Те кто в теме запрос понимают за 30 секунд. C>А что так долго-то? 30 мс не больше. Подумаешь, запрос на 5 страниц со множеством вложенных подзапросов, на который явно угробили десятки человеко-часов.
Здравствуйте, _d_m_, Вы писали:
___>Только плюс линку. Но заниматься преждевременной оптимизацией — "красивый рукопашный скрипт" — зло. Запросы надо писать так, как-будто ничего не знаешь про работу движка СУБД.
Ага. И с линком это получается намного лучше.
___>Классно. Но это хак. Оптимизатор СУБД должен этим заниматься.
Не, ну ты можешь конечно ждать, когда оптимизатор станет идеальным. Лично я предпочитаю смотреть на то, что есть в наличии.
___>PS: Речь изначально шла не об этом. Сначала gandjustas ляпнул ерунду (или коряво выразился), которую всем понять было только как: кэширование и индексы работают только для линк-запросов.
Ну, касательно ляпанья gandjustas все вопросы к нему, он много тут такой пурги несет, что одной больше, одной меньше ...
Здравствуйте, yuriylsh, Вы писали:
Y>Я отвечал на вполне конкретное заявление и iHateLogins вполне однозначно сказал то что сказал. Там не было ничего ни про массовые колличества ни про всегда плохо.
А давай мы не будем пытаться превратно трактовать, а прямо у него спросим — считает ли iHateLogins, что юнит-тесты это всегда плохо?
