Здравствуйте, Sinclair, Вы писали:
G>>Работа субд не останавливается при этом. А приложение таки надо останавливать.
Не факт. Возможно, я хреновый прогер, но бывало такое, что базу приходилось останавливать и поля менялись очень серьёзно (вплоть до объединения двух в один или даже смена типа колонки). ТАКОЕ я бы не стал делать "вживую".
Хотя ваши доводы всё равно не особо впечатляют: если уж данные такие важные, работа сервера приостанавливается (т.е. больше не принимаются соединения клиентов), делается снимок базы, обновляется и запускается параллельно, а потом удаляется устаревшая база.
Но мы опять не о том спорим — ну что у вас, Байконур что ли?? Сервер МОЖНО остановить на время, тут вопрос не о том, кого легче обновить (господи, секундное дело!), а вообще весь жизненный цикл продукта + его развитие. С кодом мы трахаемся куда больше, чем с обновлениями и вот тут эти "хранимки" — поперёк горла.
Здравствуйте, btn1, Вы писали: B>Не факт. Возможно, я хреновый прогер, но бывало такое, что базу приходилось останавливать и поля менялись очень серьёзно (вплоть до объединения двух в один или даже смена типа колонки).
Извините за вопрос не по теме, но почему вы не читаете то, что вам пишут?
Вопрос не про обновления вживую, а про невозможность атомарно проапгрейдить распределённую бизнеслогику.
B>Но мы опять не о том спорим — ну что у вас, Байконур что ли?? Сервер МОЖНО остановить на время, тут вопрос не о том, кого легче обновить (господи, секундное дело!), а вообще весь жизненный цикл продукта + его развитие. С кодом мы трахаемся куда больше, чем с обновлениями и вот тут эти "хранимки" — поперёк горла.
Ещё раз вчитайтесь в вопрос: как вы собираетесь свести обновление 1500 клиентов в 30 офисах и 11 часовых поясах к "секундному делу"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Интересно. А как происходит генерация вариантов параметров запроса? S>Как разруливаются ситуации с декомпозированными запросами, т.е. когда тело собирается кодом, расположенным в разных методах? S>Как разруливаются ситуации с декомпозицией "поперёк" границы сборок?
Спасибо за вопросы по существу.
Ключевые для понимания моменты описаны здесь.
Здравствуйте, Sinclair, Вы писали:
S>Извините за вопрос не по теме, но почему вы не читаете то, что вам пишут?
Потому что те, кому я отвечаю, съехали в какие-то дебри и толкают мысли, которые интересны только им. Может у меня что-то с русским языком, но я с трудом нахожу общность между моим
Во-первых, речь вообще не про апгрэйд, а про принципиальные возможности хранимок и кода на ЯВУ внутри модели. То есть меня интересуют не косвенные процедуры "так легче чесать левое ухо", а самое главное: работа хранимок/кода в реале и их ALM. Пока что преимуществ хранимок высказано не было, только намёки на теоретический бенефит от работы хранимки "как бы внутри" сервера.
S>Ещё раз вчитайтесь в вопрос: как вы собираетесь свести обновление 1500 клиентов в 30 офисах и 11 часовых поясах к "секундному делу"?
Я отвечу на этот второстепенный вопрос, но продолжать "тему обновлений" не вижу смысла — вы ушли от главного и мусолите детали.
1. Даже если мы возьмём систему, где широко используют хранимки, в ней всё равно не избежать какой-то логики на стороне сервера приложений (рассматриваются только трёхзвенные системы как наиболее передовая архитектура). А значит "обновления хранимок" — лишь часть того, что нужно обновлять на сервере, т.е. мы по-любому не избегаем процедуры обновления сервера.
2. Если у вас 30 филиалов, очевидно, что этим занимается далеко не один человек. Распределить задачу обновления — административная хрень.
3. Если для вас "остановить сервер, обновить, запустить" — проблема, то наверное есть смысл улучшить свою квалификацию? Есть тысячи систем, которые обновляют, и которые продолжают работать — весь вопрос лишь в аккуратности процесса и дотошности контроля качества обновления.
Вопрос "обновления" — вопрос ни о чём, с тем же успехом можно обсудить подсветку T-SQL в студии — это далеко не самое интересное в вопросе "хранимки vs код".
Здравствуйте, btn1, Вы писали:
B>Во-первых, речь вообще не про апгрэйд, а про принципиальные возможности хранимок и кода на ЯВУ внутри модели.
Принципиальные возможности одинаковые. И то и другое полно по тьюрингу.
Тем не менее в коде на ЯВУ надо писать ровно те же запросы, что и в хранимках. Поэтому вопрос как раз не в принципиальных возможностях, а во вполне конкретных проблемах, связанных с обновлением.
B>работа хранимок/кода в реале и их ALM. Пока что преимуществ хранимок высказано не было, только намёки на теоретический бенефит от работы хранимки "как бы внутри" сервера.
Как раз в ALM и есть самая проблема. В базе можно одновременно обновлять схему и логику, причем транзакционно. Если у тебя раздельное обновление кода (в приложении) и схемы (в базе), то надо обеспечить работу старого кода с новой схемой. Даже имея трехзвенное приложение с логикой на сервере, довольно сложно синхронно обновить все экземпляры сервера.
S>>Ещё раз вчитайтесь в вопрос: как вы собираетесь свести обновление 1500 клиентов в 30 офисах и 11 часовых поясах к "секундному делу"? B>Я отвечу на этот второстепенный вопрос, но продолжать "тему обновлений" не вижу смысла — вы ушли от главного и мусолите детали.
То есть хорошего решения для этого случая, кроме логики в базе, практически нет.
B>1. Даже если мы возьмём систему, где широко используют хранимки, в ней всё равно не избежать какой-то логики на стороне сервера приложений (рассматриваются только трёхзвенные системы как наиболее передовая архитектура). А значит "обновления хранимок" — лишь часть того, что нужно обновлять на сервере, т.е. мы по-любому не избегаем процедуры обновления сервера.
Неверно. Логику в базе можно инкасулировать настолько, что клиент многие изменения и не увидит. Хотя для случаев когда приложение монопольно работает с базой такой необходимости нет.
B>2. Если у вас 30 филиалов, очевидно, что этим занимается далеко не один человек. Распределить задачу обновления — административная хрень.
Хорошая отмазка для менеджмента, но по сути перекладывание с больной головы на здоровую.
B>3. Если для вас "остановить сервер, обновить, запустить" — проблема, то наверное есть смысл улучшить свою квалификацию? Есть тысячи систем, которые обновляют, и которые продолжают работать — весь вопрос лишь в аккуратности процесса и дотошности контроля качества обновления.
А если 10 серверов, все остановить? А если 24\7 клиенты ходят? А если не все серверы останавливать, то что станет когда база уже обновится, а не везде еще новый код работает?
Да, проблемы решаемые, но небесплатно. Причем чем больше проблема с обновлением клиентов для СУБД, тем выгоднее логика на стороне СУБД.
Тут нет универсального подхода.
B>Вопрос "обновления" — вопрос ни о чём, с тем же успехом можно обсудить подсветку T-SQL в студии — это далеко не самое интересное в вопросе "хранимки vs код".
По секрету скажу — установка и обновления это основные проблемы во всей разработке. В совокупности гораздо сложнее, чем все написание кода на ЯВУ обычно.
Здравствуйте, gandjustas, Вы писали:
B>>Вопрос "обновления" — вопрос ни о чём, с тем же успехом можно обсудить подсветку T-SQL в студии — это далеко не самое интересное в вопросе "хранимки vs код". G>По секрету скажу — установка и обновления это основные проблемы во всей разработке. В совокупности гораздо сложнее, чем все написание кода на ЯВУ обычно.
Ну если никто не хочет обсуждать возможности хранимок, а уходит в обновления, наверное пора перейти в другой топик?
Я и без секретов скажу: написание логики на T-SQL/PL-SQL — это адЪ (по ср. с абсолютно любым ЯВУ — Java, C#, C++). Поэтому если кто-то пытается опять как в добрые 80-ые понаписать этого хлама-на-выкид — ради бога, только руководство предупредите что "деньги будут просраны, проект — загнётся".
Сейчас даже на элементарный C# нужно тестировать каждого первого, чтобы не брать 1-месячных самоучек, а уж T-SQL... это уже "Кобол сегодняшнего дня", я б на такую тухлятину не поставил и рубля.
Здравствуйте, Sinclair, Вы писали:
S>Ещё раз вчитайтесь в вопрос: как вы собираетесь свести обновление 1500 клиентов в 30 офисах и 11 часовых поясах к "секундному делу"?
Что то мне подсказывает, что 1500 клиентов в 30 офисах, которые напрямую лезут в БД без какого либо middleware — отличный способ прострелить себе яйца ногу, вне зависимости от количества хранимок.
Здравствуйте, btn1, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>>>Вопрос "обновления" — вопрос ни о чём, с тем же успехом можно обсудить подсветку T-SQL в студии — это далеко не самое интересное в вопросе "хранимки vs код". G>>По секрету скажу — установка и обновления это основные проблемы во всей разработке. В совокупности гораздо сложнее, чем все написание кода на ЯВУ обычно.
B>Ну если никто не хочет обсуждать возможности хранимок, а уходит в обновления, наверное пора перейти в другой топик?
Какие возможности тебя интересуют?
B>Я и без секретов скажу: написание логики на T-SQL/PL-SQL — это адЪ (по ср. с абсолютно любым ЯВУ — Java, C#, C++).
Тебе все равно придется делать одни и те же запросы на T-SQL/PL-SQL. Какая еще логика тебя интересует?
Здравствуйте, gandjustas, Вы писали:
B>>Ну если никто не хочет обсуждать возможности хранимок, а уходит в обновления, наверное пора перейти в другой топик? G>Какие возможности тебя интересуют?
Я ж уже спрашивал: Есть ли какие-то особенные качества хранимок, ну просто настолько необходимые, что в 21 веке нужно писать логику при помощи СУБД-шного языка?
(это в противопоставление к коду на обычном ЯВУ, который лежит в "моделях")
B>>Я и без секретов скажу: написание логики на T-SQL/PL-SQL — это адЪ (по ср. с абсолютно любым ЯВУ — Java, C#, C++). G>Тебе все равно придется делать одни и те же запросы на T-SQL/PL-SQL. Какая еще логика тебя интересует?
Я и говорю: при одинаковых SQL запросах, есть ли какая-то серьёзная причина выбирать хранимки вместо нативного кода?
Здравствуйте, btn1, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>>>Ну если никто не хочет обсуждать возможности хранимок, а уходит в обновления, наверное пора перейти в другой топик? G>>Какие возможности тебя интересуют?
B>Я ж уже спрашивал: Есть ли какие-то особенные качества хранимок, ну просто настолько необходимые, что в 21 веке нужно писать логику при помощи СУБД-шного языка? B>(это в противопоставление к коду на обычном ЯВУ, который лежит в "моделях")
тебе уже неоднократно ответили — инкапсуляция, которая дает более простое обновление и поддержку при большом количестве различных клиентов, а также поддерживает целостность данных в сложных случаях. Последнее достигается скорее триггерами и представлениями, а не хранимками.
B>>>Я и без секретов скажу: написание логики на T-SQL/PL-SQL — это адЪ (по ср. с абсолютно любым ЯВУ — Java, C#, C++). G>>Тебе все равно придется делать одни и те же запросы на T-SQL/PL-SQL. Какая еще логика тебя интересует?
B>Я и говорю: при одинаковых SQL запросах, есть ли какая-то серьёзная причина выбирать хранимки вместо нативного кода?
Да, см выше.
Разница по сути небольшая, именно потому что запросы одинаковые будут, а они составляют большую часть sql кода.
Здравствуйте, gandjustas, Вы писали:
G>тебе уже неоднократно ответили — инкапсуляция, которая дает более простое обновление и поддержку при большом количестве различных клиентов
Если не умеешь внимательно читать — злись на себя, а не упрекай. Для тех, кто в танке/с берушами/под косяком:
B>1. Даже если мы возьмём систему, где широко используют хранимки, в ней всё равно не избежать какой-то логики на стороне сервера приложений (рассматриваются только трёхзвенные системы как наиболее передовая архитектура). А значит "обновления хранимок" — лишь часть того, что нужно обновлять на сервере, т.е. мы по-любому не избегаем процедуры обновления сервера.
G>Неверно. Логику в базе можно инкасулировать настолько, что клиент многие изменения и не увидит.
Если ты собрался городить 3-звенку на вот этом маразме из хранимок, это не означает, что все поддерживают это мнение. Более того — архитектурно это верблюд. Сервер приложений для того и придумали, что СУБД — всего-лишь хранилище, причём заменяемое (в идеале) на любое другое (выбор оптимального или которое есть у клиента), а сервер приложений остаётся неизменным и не страдает от диалектов СУБД. Короче, ответ "так легче обновляться" — слишком узкий и в плане 3-звенок вообще бессмысленный.
IT>Это ты всего лишь автоматизировал поиск костылей. Linq устраняет сами костыли. Если они у тебя где-то остались, то ты просто не сможешь скомпилировать приложение.
А можно вот так написать. Я устранил проблемы связанные с динамическим SQL, а LINQ всего лишь предлагает новую модель костылей. Всё же предлагаю вести диалог в более предметном ключе. Предлагаю сравнивать LINQ и автоматически проверяемый динамический SQL. Разве есть принципиальная разница: не скомпилируется или не пройдет CheckAllQueries?
Что касается рефакторинга одной кнопкой, то Москва не сразу строилась, прикрутить к моему подходу рефакторинг одной кнопкой тоже можно. Но, честно говоря, в наших проектах время, затраченное на переименование колонки или таблицы пока не настолько велико, чтобы получить видимый выигрыш от продолжения автоматизации рефакторинга.
Вопрос лишь в поддержке со стороны инструментов: ReSharper-а? Или есть принципиальные вопросы?
Отдельный вопрос про LINQ. Вопрос про ассоциации. Откуда они беруться? В реляционных СУБД никаких ассоциаций нет. Там нет такого понятия. Есть только ограничения для поддержания данных в согласованном состоянии. И только эту роль в реляционных СУБД играют внешние ключи. В запросах внешние ключи не используются (кстати, в dbforge отличный автокомплит по FK). Интересно задаться вопросом, почему за многолетнюю историю SQL не один из вендоров не ввел ассоциации, как термин, как элемент метаданных и как элемент синтаксиса SQL? Может оно и не очень востребовано? Может автокомплита по FK достаточно?
LINQ запросы по ассоциациям поддерживает. Поддерживает он ассоциации, потому что рожден в C#/VB, где отдельного понятия "ассоциации" тоже нет, есть свойства. Таким образом, надо ссылочные свойства сишарпа куда-нибудь промэпить в реляционную модель. Вопрос куда? И сколько телодвижений требуется от программиста? Как видим, вопрос про ассоциаци связан с тем, что мы исповедуем code first или database first? Code first по сути своей гибридный подход: часть базы определяется в C# коде, часть обычными командами DDL. А такая гибридизация, т.е. двойственность, сама может породить проблемы. Database first выглядит более логичным подходом. Тогда C# классы полностью автоматически генерируются по базе. Но как генерируются ассоциации? По FK? А вдруг мне придется снять ограничения целостности, и что мне переписывать все запросы?
Это я всё к чему. К тому, что если уж добавляется какая-то фича в инструментарий для разработчика, то пусть она добавляется по всему стеку, например, если мы используем реляционную СУБД и хотим добавить фичу "запросы по ассоциациям", то это должно быть поддержано и самой СУБД. Мэпинговый (ORM) подход почти наверняка содержит скрытую accidental complexity. Если язык СУБД плох, так давайте улучшать этот язык, а не городить мэпинги. Но, к сожалению, Хейлсберг не хочет just talk to a database:
We could've probably shipped something like LINQ much quicker if we said, "Let's just jam SQL in there or something that is totally SQL Server-specific, and we'll just talk to a database and then we'll have it," but it's not general enough to merit existence in a general-purpose programming language. You very quickly then become a domain-specific programming language, and you live and die by that domain. http://broadcast.oreilly.com/2009/03/an-interview-with-anders-hejls.html
Т.е. одни делают general-purpose язык, другие делают СУБД, а проблемы совместного использования оставляют прикладным разработчикам.
SqlCommand/SqlReader никакого мэпинга не требуют, работают с СУБД на ее родном языке. SqlCommand/SqlReader не поддерживают статическую проверку запросов? У меня такая проверка добавлена.
Кстати, почему в Java 8 сделали LINQ to Object и не сделали LINQ to Database? Вот мнение:
...
Do it "bottom-up", putting most focus on your SQL / relational domain model. In that case, use JDBC or jOOQ and again, transform your results using the Java 8 Streams API.
...
We need true SQL for relational database querying, and we need the Java 8 Streams API for functional transformations of in-memory collections. That's it. Go Java 8! http://tech.pro/blog/1689/does-java-8-still-need-linq-or-is-it-better-than-linq
НС>Потому что в языке нет механизма цитирования кода.
Почему C# 3.0 сделали недоцитирование, а в Java8 не сделали? Если бы речь шла о полноценном цитировании, как в Lisp, еще можно было понять. А так это недоцитирование, может поэтому и не сделали в Java8?
Здравствуйте, Alexander Polyakov, Вы писали:
НС>>Потому что в языке нет механизма цитирования кода. AP>Почему C# 3.0 сделали недоцитирование, а в Java8 не сделали?
Потому что и языки и люди, их разрабатывающие, разные, ваш КО.
Здравствуйте, btn1, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>тебе уже неоднократно ответили — инкапсуляция, которая дает более простое обновление и поддержку при большом количестве различных клиентов
B>Если не умеешь внимательно читать — злись на себя, а не упрекай. Для тех, кто в танке/с берушами/под косяком:
B>
B>>1. Даже если мы возьмём систему, где широко используют хранимки, в ней всё равно не избежать какой-то логики на стороне сервера приложений (рассматриваются только трёхзвенные системы как наиболее передовая архитектура). А значит "обновления хранимок" — лишь часть того, что нужно обновлять на сервере, т.е. мы по-любому не избегаем процедуры обновления сервера.
Ты сам-то читать умеешь? На это уже отвечал. С логикой на стороне субд необходимости в обновлении сервера меньше. Кроме того код, не завязанный на хранение данных, обновлять проще. Код, который завязан на хранение вынужден поддерживать базу как до обновления, так и после.
G>>Неверно. Логику в базе можно инкасулировать настолько, что клиент многие изменения и не увидит.
B>Если ты собрался городить 3-звенку на вот этом маразме из хранимок, это не означает, что все поддерживают это мнение. Более того — архитектурно это верблюд.
Это слова ни о чем. Пусть верблюд, это лучше чем самописные утконосы.
B>Сервер приложений для того и придумали, что СУБД — всего-лишь хранилище, причём заменяемое (в идеале) на любое другое (выбор оптимального или которое есть у клиента), а сервер приложений остаётся неизменным и не страдает от диалектов СУБД.
Это кто тебе такую глупость сказал?
Трехзвенка появилась потому что веб пошел в массы. До веба трехзвенка была экзотикой и толком никто не знал зачем оно надо.
Если СУБД всего лишь хранилище, то почему её стоимость выше стоимости приложения? Особенно если посмотреть на оракл. А если столько платить, то какой смысл использовать как «всего-лишь хранилище». На практике «всего-лишь хранилище» обеспечивает целостность данных и конкурентный доступ, а также работает эффективно на таких объемах, что врукопашную повторить это нельзя за разумное время. Вот поэтому и пишут логику на стороне субд.
B>Короче, ответ "так легче обновляться" — слишком узкий и в плане 3-звенок вообще бессмысленный.
Ты сам себе противоречишь. Чем больше логики инкапсулировано внутри субд, тем проще поменять субд, ибо нет завязки на диалекты sql.
Здравствуйте, Alexander Polyakov, Вы писали:
IT>>Это ты всего лишь автоматизировал поиск костылей. Linq устраняет сами костыли. Если они у тебя где-то остались, то ты просто не сможешь скомпилировать приложение. AP>Я устранил проблемы связанные с динамическим SQL
Устранил? Не смеши мои тапочки.
Бери код и покажи проект, который автоматом проверит все запросы на корректность http://samsaffron.com/archive/2011/09/05/Digging+ourselves+out+of+the+mess+Linq-2-SQL+created
Не забываем что Linq проверяет все сам, без дополнительных телодвижений со стороны разработчика.
AP>Разве есть принципиальная разница: не скомпилируется или не пройдет CheckAllQueries?
Да, разница огромная. CheckAllQueries не работает с динмическим SQL.
Filter? filter = Filter.Suggested;
Option<string> search = "%test%";
var paging = BatchQuery<Paging<ITagSynonym, int?>>.New(new {
filter, user = new {IsAnonymous = false, IsModerator = false, Id = 1}, tagScoreRequiredToVote = 10,
search, tab = Tab.Newest, start = 0, pageSize = 20
}, @"
SELECT TagSynonyms.Id, SourceTagName, TargetTagName, OwnerUserId, ApprovalDate, TagSynonyms.CreationDate,
AutoRenameCount, Score, SourceTags.Id AS SourceTagId, TargetTags.Id AS TargetTagId, Users.DisplayName
@MainQuery()
ORDER BY
@switch (tab) {
case Tab.Newest:
@:CreationDate DESC, Id
break;
case Tab.Master:
@:TargetTagName ASC, AutoRenameCount DESC, Id
break;
case Tab.Synonym:
@:SourceTagName ASC, AutoRenameCount DESC, Id
break;
case Tab.Votes:
@:Score DESC, TargetTagName ASC, AutoRenameCount DESC, Id
break;
case Tab.Creator:
@:DisplayName, Id
break;
case Tab.Renames:
@:AutoRenameCount DESC, TargetTagName, Id
break;
}
OFFSET @start ROWS FETCH NEXT @pageSize ROWS ONLY
OPTION (OPTIMIZE FOR (@start = 0, @pageSize = 20));
SELECT COUNT(*) @MainQuery();
@helper MainQuery() {<text>
FROM TagSynonyms
LEFT JOIN Tags SourceTags ON SourceTagName = SourceTags.Name
LEFT JOIN Tags TargetTags ON TargetTagName = TargetTags.Name
LEFT JOIN Users ON Users.Id = OwnerUserId
WHERE 1 = 1
@switch (filter) {
case Filter.Active:
@:AND ApprovalDate IS NOT NULL
break;
case Filter.Suggested:
@:AND ApprovalDate IS NULL
if (!user.IsAnonymous && !user.IsModerator) {
@:AND TargetTagName IN (@TargetTagNames())
}
break;
case Filter.Merge:
@:AND ApprovalDate IS NOT NULL AND ISNULL(SourceTags.Count, 0) > 0
break;
}
@if (search.HasValue) {
@:AND (SourceTagName LIKE @search OR TargetTagName LIKE @search)
}
</text>}
@helper TargetTagNames() {<text>
SELECT Name
FROM Tags
WHERE Id IN (SELECT Id
FROM UserTagTotals
WHERE UserId = @user.Id
AND TotalAnswerScort > @tagScoreRequiredToVote)
</text>}").Result();
var rows = paging.Rows;
var count = paging.Count;
G>Да, разница огромная. CheckAllQueries не работает с динмическим SQL.
Ты читать не умеешь? Там всё начинается с динамического SQL.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>>>Я устранил проблемы связанные с динамическим SQL G>>Устранил? Не смеши мои тапочки. G>>Бери код и покажи проект, который автоматом проверит все запросы на корректность http://samsaffron.com/archive/2011/09/05/Digging+ourselves+out+of+the+mess+Linq-2-SQL+created AP>В чем проблема?
Еще раз: Весь код (проект), который проверяет все возможные запросы при компиляции.
G>>Да, разница огромная. CheckAllQueries не работает с динмическим SQL. AP>Ты читать не умеешь? Там всё начинается с динамического SQL.
И заканчивается тонной тестов, которые не явлются проверкой при компиляции.
Как раз читать я умею, даже умею читать то, что явно не написано.
