Transact SQL + C#

[Ivan Korneychuk]

Ну хоть кто то меня поддержал

[Erkin Kuchkarov]

Сообщение от Ivan Korneychuk

Ну хоть кто то меня поддержал

Угу... два менеджера - торгаша учат программировать. Ухахататься можно.

[Timur Naimov]

Сообщение от Erkin Kuchkarov

Угу... два менеджера - торгаша учат программировать. Ухахататься можно.

Коллега, ну Вы меня понимаете.....

[Alexandr Pavlenko]

Сообщение от Timur Naimov

И у всех одно и тоже мнение - "ощющение что им платят за количество кода...."

Считаю, что знакомство с несколькими индийскими программистами не составляют полную картину о них. Если честно, тот факт что им за "чтото" платят на международном рынке в сфере разработки программ уже много стоит и о многом говорит, вам не кажется???

[Alexandr Pavlenko]

Сообщение от Erkin Kuchkarov

Угу... два менеджера - торгаша учат программировать. Ухахататься можно.

Угумс...давайте я вам дам проект ... вы его сделаете..а потом все вместе посмеемся...

[Andrew Sklyarevsky]

Сообщение от Timur Naimov

Особую легкость Вы испытаете когда какой-нить Вася Пупкин случайно удалит файлик аксеса ))) Лично мне легче или попросить заказчика "пересесть" на SQL Server или отказаться. Почему так объяснять думаю не надо - аксес и SQL Server не сравнимы...

Честно говоря, я не работал с Access, но мне известно, что он имеет свою нишу. Понятное дело, что SQL Server куда более продвинутая СУБД.

Сообщение от Timur Naimov

Вопрос спорный. ORM безусловно очень сильно помогает. Но от хранимых процедур все равно никуда не деться. Не все к сожалению можно при помощи ORM реализовать.

Не знаю, не знаю . Что например нельзя реализовать при помощи ORM? Разве что, процедуру бекапа, может быть, лучше, оставить в виде хранимой процедуры . Лично мне ещё не нравится, что хранимые процедуры находятся в БД, отдельно от кода. Гораздо удобнее, когда всё находится в одном месте (т.е. внутри Visual Studio solution) и редактировать, соответственно, нужно меньше (если мы используем ORM).

Сообщение от Timur Naimov

Ну а про OLAP вообще говорить не приходится. Не могу представить себе ни один проект для автоматизации чего-нибудь (если только не программулька из 2-х окон), где бы его не использовали.

OLAP мощная технология, но существует миллион задач где она совсем не нужна и ни к месту. Если у Вас такого рода проекты, где использование OLAP очень к месту - здорово, но есть и Веб-сервисы, в которых маленькую аналитику сделать проще без OLAP в силу разных причин.

Сообщение от Timur Naimov

Опять же очень спорное мнение. Индийские программисты бывают разные... но в большинстве своем ..... наверное всетаки самые дешевые.... У меня есть несколько друзей программистов, которые сталкивались с ними в живую. И у всех одно и тоже мнение - "ощющение что им платят за количество кода...."

По некоторым данным, зарплаты индийских программистов достигли российского уровня.

Сообщение от Timur Naimov

Ну а что касается приведенного ранее кода - совершенно не оптимальное решение. Стринг - он загадочный, а точнее "неизменяемый". И в цикле выполнять конкатенацию "плюсиком" - в приведенном примере будет создаваться 6!!!! строк на каждой итерации. Вот и посчитайте сколько памяти это все будет занимать. Гораздо лучше в самом запросе выполнить конкатенацию значений полей. Что-то вроди "select field1 + field2 + field3 as ......".

Иногда хороши запросы, а иногда хорошо это делать в памяти (правда тогда лучше конечно использовать String.Format или StringBuilder, по производительности это оптимальнее начиная с соединения 3-х строк). Например, если какую-либо информацию пользователь редактирует и объекты в памяти меняются - зачем лезть в БД снова за объектом?

Ещё есть такой момент, как отношение стоимости потраченного на оптимизации времени к стоимости оборудования, которое могло бы позволить решать эти задачи и без каких-либо оптимизаций. Иногда бывает так, что проще купить сервер по-лучше. Но это я конечно не говорю к тому, что надо прямо писать как попало ничего не оптимизируя. Это я к разумности, за лишними оптимизациями и подсчётом каждого байта не всегда надо гнаться. Иногда достаточно сделать чтобы это работало, а дальше - посмотрим. Программист из любого проекта чему-нибудь научиться в любом случае .

[shumbola]

Сообщение от Andrew Sklyarevsky

Лично мне ещё не нравится, что хранимые процедуры находятся в БД

Возмите и добавьте их в свой проект. Никто вас ругать не будет, Visual Studio тоже :-)

[Timur Naimov]

Сообщение от Alexandr Pavlenko

Если честно, тот факт что им за "чтото" платят на международном рынке в сфере разработки программ уже много стоит и о многом говорит, вам не кажется???

Нет не кажется. То что нашим гасторбайтерам "чтото" платят на международном строительном рынке не говорит вообще ни о чем Я не подвожу всех индусов под одну гребенку. Я ж русским по белому написал что они разные. И далее просто привел ЛИЧНЫЙ опыт.

Сообщение от Alexandr Pavlenko

Угумс...давайте я вам дам проект ... вы его сделаете..а потом все вместе посмеемся...

Так Вы начальник чтобы проекты раздавать или руководитель проекта или программист? Или специалист широчайшего профиля Но раз пошла такая пьянка... мы с Эркином с удовольствием тряхнем стариной и чего-нибудь там напишем.... Сами не справимся Алимака еще позовем Кстати меня не удивит если Вы не знаете о ком идет речь знающие люди поймут

Сообщение от Andrew Sklyarevsky

Что например нельзя реализовать при помощи ORM?

Я ж привел пример про Crystal Report.

Сообщение от Andrew Sklyarevsky

Лично мне ещё не нравится, что хранимые процедуры находятся в БД

Даже не знаю что и сказать.... На то они и хранимые процедуры чтобы там находится наверное.... Их кстати можно редактировать прямо из VS, причем это даже удобнее иногда чем в SQL Management Studio. Так что создается впечатление что "всё находится в одном месте (т.е. внутри Visual Studio solution)"

Сообщение от Andrew Sklyarevsky

OLAP мощная технология, но существует миллион задач где она совсем не нужна и ни к месту.

Согласен. Все на OLAP сделать нельзя. Я говорил о тех задачах, где необходима именно аналитика, причем любого уровня. Сделать можно как угодно, но правильнее всего на OLAP.

Сообщение от Andrew Sklyarevsky

Иногда хороши запросы, а иногда хорошо это делать в памяти

Я комментировал приведенный ранее код. Но в целом важно найти правильный баланс.

Сообщение от Andrew Sklyarevsky

Это я к разумности, за лишними оптимизациями и подсчётом каждого байта не всегда надо гнаться.

Учитывая специфику технологии .NET гнаться за каждым байтом наверное даже глупо... Я не говорю об оптимизации каждой строчки кода. Но нужно придерживаться общих принципов как делать правильно, а как нет.

В общем мораль сей басни такова - нужно прислушиваться к тому что говорят умные люди (ни в коем случае не имею ввиду себя), читать книги признанных авторитетных авторов, смотреть на мировой опыт и тенденции рынка, пересать изобретать вилосипеды в промышленных масштабах и делать не так как хочется или проще а так как ПРАВИЛЬНО. И тогда будет всем нам счастье...

[Andrew Sklyarevsky]

Сообщение от Timur Naimov

а так как ПРАВИЛЬНО

Вы же наверняка понимаете, что нет единственно правильного метода написания кода . Если же есть, то мне было бы интересно почитать документацию "правильного" метода .

А насчёт признанных авторов, в целом, читать конечно полезно, но брать за абсолютную истину тоже не стоит. Особенно если учесть, как быстро развивается отрасль и как быстро подходы устаревают.

Изобретение же велосипедов, учащимся людям может быть очень полезным занятием. Например, гораздо проще понять суть ORM попробовав написать свой.

Сообщение от Timur Naimov

Я ж привел пример про Crystal Report.

Это 1 компонент из многих. Если его написали не универсально, то это показывает его с не очень хорошей стороны. Я же имел ввиду разработку функциональности связанной со взаимодействием с пользователем (аналитика ведь только выводит информацию). Всё куда быстрее пишется через какой-нибудь ORM, чем используя просто DataReader. Кстати, по сути, типизированные DataSet-ы тоже являются ORM-ом.

Сообщение от Timur Naimov

Я комментировал приведенный ранее код. Но в целом важно найти правильный баланс.

Так создатель темы же написал:

Сообщение от Anton Papin

Да и табличка у меня не шибко большая.

Значит, код работает и запаса масштабируемости у подхода достаточно .

Сообщение от shumbola

Возмите и добавьте их в свой проект. Никто вас ругать не будет, Visual Studio тоже :-)

Но ведь удобнее же работать с типизированными ORM-ами или с LINQ, чем с SQL процедурами, которые ещё надо привязывать к объектам своим способом. Допустим, если у меня есть метод GetSuperCustomers с хитрым фильтром, то мне будет удобнее смотреть на этот метод, когда запрос находится прямо в нём (не строковый SQL, конечно, а в виде ORM-запроса - критериев, предикатов или LINQ). Т.е. запрос, написанный на C#, часто бывает удобнее запроса, написанного на SQL и хранящегося в другом месте.

Сообщение от Timur Naimov

Но в целом важно найти ... баланс.

Согласен, и мы все об этом и пишем . При всём уважении, не ясна только позиция господ менеджеров. Ведь задали вопрос – желательно отвечать, а не объяснять всем, какие вы опытные товарищи.

[Timur Naimov]

Сообщение от Andrew Sklyarevsky

Вы же наверняка понимаете, что нет единственно правильного метода написания кода . Если же есть, то мне было бы интересно почитать документацию "правильного" метода .

Если бы я его знал... наверное не в Шарифе работал бы и не в Узбекистане вообще ПРАВИЛЬНО имеется ввиду с соблюдением общих принципов и рекомендаций. Как правильно написать конкретный проект никто никогда не скажет. Но то что нужно вместо операции с "плюсиком" в цикле со строками пользоваться StringBuilder'ом, то что для аналитики нужно исользовать OLAP, то что при необходимости использовать все-таки запрос к БД а не ORM лучше использовать хранимую процедуру..... и т.д. знать нужно. И это я называю ПРАВИЛЬНЫМ написанием кода. И именно это написано в книгах, статьях и прочей документации. Имеено это советы тех умных людей о которых я писал раньше. И я призываю помнить эти советы и использовать их в своей профессиональной деятельности по той простой причине что вы господа программисты. Можно все конечно сделать по своему.... но мне кажется что лучше все-таки не изобретать велосипед Если Вы считаете эти рекомендации несостоятельными и

Сообщение от Andrew Sklyarevsky

А насчёт признанных авторов, в целом, читать конечно полезно, но брать за абсолютную истину тоже не стоит.

... то предлагаю Вам стать одним из этих авторов и развить эту мысль там..

Сообщение от Andrew Sklyarevsky

Значит, код работает и запаса масштабируемости у подхода достаточно .

Автор забыл указать динамику роста размера БД.

Сообщение от Andrew Sklyarevsky

При всём уважении, не ясна только позиция господ менеджеров. Ведь задали вопрос – желательно отвечать, а не объяснять всем, какие вы опытные товарищи.

Если внимательно посмотрите историю этой ветки - то ответ был дан до моего первого сообщения. Я всего лишь уточнил при чем тут все-таки "Transact SQL" . И свои комментарии по коду тоже дал.. Так что мы тут по теме тоже отвечаем... И немного лирики, без этого никак