Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
 Re: Ну вот и дождались Юкона  [new]
Naug
Member

Откуда:
Сообщений: 663
автор
Сравнивать .NET и JAVA не возьмусь потому как опыта здесь считаю маловато.

А чего тут сравнивать? .NET очень плохо синтегрирован с IntelliJ IDEA.
8 ноя 05, 13:33    [2046898]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
yukon2005
Guest
Собственно, читайте заголовок "Comparing ... for Microsoft .NET Developers".
Тех кто не ".NET Developers" - это не касается, зато те кто ".NET Developers" скорее выберут Yukon2005 в силу вышеизложенного.
И незачем воду лить.
8 ноя 05, 13:48    [2047026]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Yo!!
Guest
yukon2005
Собственно, читайте заголовок "Comparing ... for Microsoft .NET Developers".
Тех кто не ".NET Developers" - это не касается, зато те кто ".NET Developers" скорее выберут Yukon2005 в силу вышеизложенного.
И незачем воду лить.


ага, для субд важнейшая характеристика это интеграция .Net/Java :) жава-девелопер обязан выбрать оракл, .Net mssql2005, да ? а хто же вибирал mssql2k до сегоднешнего дня ?
8 ноя 05, 13:54    [2047075]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
yukon2005
Собственно, читайте заголовок "Comparing ... for Microsoft .NET Developers".
Тех кто не ".NET Developers" - это не касается, зато те кто ".NET Developers" скорее выберут Yukon2005 в силу вышеизложенного.
И незачем воду лить.


Yukon2005 или оракл всё таки будут выбирать DB Developers и вышеизложенное мало повлияет на этот выбор.
Или кто-то выбирал оракл из-за явы?
8 ноя 05, 14:43    [2047350]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
SergSuper
Yukon2005 или оракл всё таки будут выбирать DB Developers и вышеизложенное мало повлияет на этот выбор.

Когда создается приложение или система, выбирает не некая каста DB Developers, а команда разработчиков и критериев там много. И если эта команда .NET разработчиков, то им очевидно будет проще и удобнее сопрягаться с Yukon, нежели чем с чем-нибудь другим.
Или вы этого сами не осознаете, или это еще как-то по другому разжевывать надо?
Тем более, что и так понятно, что это входит в стратегию MS о тесной интеграции (но только в рамках MS и по ее правилам).
А остальные, выходит, то же пляшут под ее дудку - тот же оракл, вынужденно включивший хоть какую-то поддержку .NET.
8 ноя 05, 17:03    [2048418]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Dooma
И если эта команда .NET разработчиков, то им очевидно будет проще и удобнее сопрягаться с Yukon, нежели чем с чем-нибудь другим.
Или вы этого сами не осознаете, или это еще как-то по другому разжевывать надо?

Разжуйте, что ли.
Что вообще такое .NET разработчики? Я так понимаю что это кто пишет клиентов на НЕТе. Им вобщем-то пофиг чего есть внутри сервера, а снаружи как был ADO.NET так он и остаётся. Либо это разработчики БД, которым надоело писать на SQL и они решили вспомнить молодость и пошли циклами на C#... Тогда да, тогда осознал
Не, ну правда - чего с чем интегрировать? xp_ процедуры будет легче писать, но так ли часто оно надо?
А на оракл не надо ссылать, давайте своими словами
8 ноя 05, 17:40    [2048661]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
SergSuper
Yukon2005 или оракл всё таки будут выбирать DB Developers и вышеизложенное мало повлияет на этот выбор.
Или кто-то выбирал оракл из-за явы?
К сожалению, MSSQL (в отличие от других СУБД) выбирают не DB Developers, а VB programmers. :-(
Собственно, это стратегия микрософта, и из-за этого MS бросила титанические усилия на встраивание в MSSQL .NET-а, отвлекая силы от остального.

Конечно, в серьёзных проектах СУБД выбирают DB Developers, и они понимают, время жизни и развития языка или среды программирования (типа .NET) намного меньше времени жизни БД. Но на объём продаж эти проекты не влияют...
8 ноя 05, 18:11    [2048852]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
SergSuper

Что вообще такое .NET разработчики? Я так понимаю что это кто пишет клиентов на НЕТе. Им вобщем-то пофиг чего есть внутри сервера, а снаружи как был ADO.NET так он и остаётся.
Ну да, ну да. Это такие лохи, которые пишут простые запросы и процедуры через ADO.NET на простом SQL-92 (да и то максимум из одного селекта), без учета Transact или PL/SQL расширений, поскольку очевидно, что эти сложные диалекты доступны только неким мудрым SQL Developer-ам
А еще это люди, которых совершенно не волнует разработка сложных многозвенных приложений и им не интересно где у них будет бизнес-логика.
А такие вещи как "Query Notification through ADO.NET" их и подавно не интересуют.

SergSuper

Либо это разработчики БД, которым надоело писать на SQL и они решили вспомнить молодость и пошли циклами на C#
Кто такие разработчики БД? В вашем понимании, очевидно, это некая элитная каста. Видимо, вам приятно о себе так думать. Ну что же, наслаждайтесь нарцисизмом :)
Если вы имеете в виду архитекторов БД. То даже такие люди зачастую не занимаются написанием тысяч запросов, процедур и функций. Более того во многих случаях, в командах разработчиков многие обязанности и нагрузки могут многократно пересекаться, за исключением может быть, разработки общей идеологии и структуры.

alexeyvg
К сожалению, MSSQL (в отличие от других СУБД) выбирают не DB Developers, а VB programmers. :-(
К слову, никогда не писал, на VB (только на c++/delphi/c#), но видел много удачных комерческих проектов. Например, специлизированные программы для диллеров Toyota и Nissan. Так, что напрасно вы ...
8 ноя 05, 19:45    [2049205]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Dooma
Какие-то скользкие у Вас ответы. Давайте поконкретней
Ну да, ну да. Это такие лохи, которые пишут простые запросы и процедуры через ADO.NET на простом SQL-92 (да и то максимум из одного селекта), без учета Transact или PL/SQL расширений, поскольку очевидно, что эти сложные диалекты доступны только неким мудрым SQL Developer-ам
Очевидно это шутка, но я юмора не понял. Наверное от избытка нарцистизма.

А еще это люди, которых совершенно не волнует разработка сложных многозвенных приложений и им не интересно где у них будет бизнес-логика.
Вот тут вроде чего-то понимаю.Т.е. можно будет писать некие модули на процедурных языках, а работать они будут на том же сервере. Если учесть что эти процедурные языки всё равно будут общаться с данными сервера через ADO.NET то для разработчика разница получается небольшая. Гораздо логичней было бы ввести необходимые элементы в T-SQL(как в оракле). Как-то странно для фирмы, которая пишет компилляторы, столь бедный логическими элементами язык. А получается что за 10 лет он обогатился только обработкой исключений.

А такие вещи как "Query Notification through ADO.NET" их и подавно не интересуют.
Во-первых не уверен что эта вещь будет активно использоваться, а во вторых что-то подобное есть и в оракле и не думаю что сделать к ней НЕТ-интерфейс будет большая проблемма.
В общем на мой взгляд эта опция не может повлиять на выбор.

Кто такие разработчики БД? В вашем понимании, очевидно, это некая элитная каста. Видимо, вам приятно о себе так думать. Ну что же, наслаждайтесь нарцисизмом :)
Я пытался представить кто такие НЕТ-разработчики и чего они делают. До сих пор не представляю.

Если вы имеете в виду архитекторов БД. То даже такие люди зачастую не занимаются написанием тысяч запросов, процедур и функций. Более того во многих случаях, в командах разработчиков многие обязанности и нагрузки могут многократно пересекаться, за исключением может быть, разработки общей идеологии и структуры.
Обязанности то может и пересекаются, только вот методы работы с данными и с написанием всего остального не пересекаются.

alexeyvg
К сожалению, MSSQL (в отличие от других СУБД) выбирают не DB Developers, а VB programmers. :-(

А вы бросайте этот высокомерный тон и учите VB :)
В принципе это даже и не шутка. Пусть VB programmer (в Вашем понимании этого слова) делает плохие БД, пусть они медленно работают. Мы можем сколь угодно их справедливо критиковать. Но они работают и требования заказчика выполняют. Да, Вы сейчас будете говорить что когда-то придет день когда это всё завалится, что нет маштабируемости т.д. Но день не приходит, а оно работает. Так может работодатели, которые выбрали не Вас, дорогого специалиста, которому надо много платить, а VB programmer-а правы?
Вобще-то конечно утрированно(уже представляю мощщщный ответ), но тенденция налицо.
9 ноя 05, 00:20    [2049606]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
Пример удобства юкона с точки зрения .НЕТ разработчиков уже был приведен и обсуждался тут:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=143322&pg=4&hl=execute#1171756

Если разработчики ничего кроме .НЕТ-а не знают, то так писать запросы им, конечно, удобно. Срвнивать не с чем.

А если они вдруг знают хотя бы TSQL, то поймут, что даже на TSQL-е запросы пишутся и отлаживаются быстрее, чем на этом интегрированном убожестве.
9 ноя 05, 04:46    [2049738]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
Dooma
alexeyvg
К сожалению, MSSQL (в отличие от других СУБД) выбирают не DB Developers, а VB programmers. :-(
К слову, никогда не писал, на VB (только на c++/delphi/c#), но видел много удачных комерческих проектов. Например, специлизированные программы для диллеров Toyota и Nissan. Так, что напрасно вы ...


SergSuper
alexeyvg
К сожалению, MSSQL (в отличие от других СУБД) выбирают не DB Developers, а VB programmers. :-(

А вы бросайте этот высокомерный тон и учите VB :)
В принципе это даже и не шутка. Пусть VB programmer (в Вашем понимании этого слова) делает плохие БД, пусть они медленно работают. Мы можем сколь угодно их справедливо критиковать. Но они работают и требования заказчика выполняют. Да, Вы сейчас будете говорить что когда-то придет день когда это всё завалится, что нет маштабируемости т.д. Но день не приходит, а оно работает. Так может работодатели, которые выбрали не Вас, дорогого специалиста, которому надо много платить, а VB programmer-а правы?
Вобще-то конечно утрированно(уже представляю мощщщный ответ), но тенденция налицо.
Ничего не хотел плохого сказать про VB и VB-программистов. Сам когда-то писал много на нём.

Я просто говорю про разное позиционирование СУБД, и вместо VB могу написать Java или C#.

Для средних и крупных компаний и сложного софта время жизни БД велико и никакой язык и платформа не живёт столько, сколько живёт БД компании. Да и нет программиста или аналитика, который знает всю функциональность системы.

Соответственно, при разработке СУБД ориентироваться на языки написания клиента бессмысленно - много их сменится за время жизни БД, об иных и забудут.

Вот Оракл и ИБМ позиционируют свои СУБД на такой рынок, они для себя считают такую стратегию более правильной.

А МС считает более правильной ориентацию на маленькие проекты, живущие небольшое время - проект быстренько делают, причём БД делает не разработчик БД, а программист, немножко поэксплуатируют, а потом приходит новый программер и переписывает всё заново. Ну, всё это с вариациями, конечно.

Мне, как человеку, работающему с MSSQL, хочется, чтобы ориентация в МС была ближе к первому варианту.
9 ноя 05, 10:06    [2050180]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
c127
А если они вдруг знают хотя бы TSQL, то поймут, что даже на TSQL-е запросы пишутся и отлаживаются быстрее, чем на этом интегрированном убожестве.
Вот-вот :-)

.НЕТ мне очень нравится, но работать с реляционной БД нужно через соответствующий язык, а не циклами на C#.
9 ноя 05, 10:10    [2050202]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
хех. а как же уникальная возможность написать свой собственный вариант nested loops ;)?

---
Vae victis!
9 ноя 05, 17:25    [2052714]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
а дурацкая возможность...
и не надо теперь всех тыкать в то, что все кинуться на NET писать хранимки... Большинству хватит знаний, чтобы использовать только TSQL. и использовать NET только в обоснованных ситуациях, а не как попало и везде...

Как уже было сказано, ораклисты не слишком на джаве ваяют, хотя возможность есть давно. Почему здесь будет по другому?
9 ноя 05, 18:04    [2052919]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
AAron
Как уже было сказано, ораклисты не слишком на джаве ваяют, хотя возможность есть давно. Почему здесь будет по другому?


тов. судья а он не может :)
9 ноя 05, 22:53    [2053701]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
AAron
а дурацкая возможность...
и не надо теперь всех тыкать в то, что все кинуться на NET писать хранимки... Большинству хватит знаний, чтобы использовать только TSQL. и использовать NET только в обоснованных ситуациях, а не как попало и везде...


Правильно, но в таком случае мелкософту не нужно было (и сейчас не нужно) кричать о революции в технологиях. И легкость интегрирования сервера с верхним уровнем тоже сказки, присутсвие .НЕТ-а на сервере ее не облегчает. ИМХО серверная часть удобнее пишется на специально созданном языке сервера, типа PL/SQL, и вызывается из верхнего уровня с помощью языка, который там работает, например из жабы или C#.

AAron

Как уже было сказано, ораклисты не слишком на джаве ваяют, хотя возможность есть давно. Почему здесь будет по другому?


И я о том же, никому оно не надо. Не нужно писать чушь типа: "Dooma>И если эта команда .NET разработчиков, то им очевидно будет проще и удобнее сопрягаться с Yukon, нежели чем с чем-нибудь другим." Это мелкософту так бы хотелось. Но на самом деле .НЕТ сопрягается без проблем со всем у кого есть .НЕТ драйвер, так что при выборе сервера лучше использовать более существенные соображения. Дешевле обойдется.
10 ноя 05, 03:52    [2053876]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
c127
Это мелкософту так бы хотелось. Но на самом деле .НЕТ сопрягается без проблем со всем у кого есть .НЕТ драйвер, так что при выборе сервера лучше использовать более существенные соображения. Дешевле обойдется.

Вот вот - вся их интеграция .NET и MSSQL - чистой воды никому не нужный маркетинговый ход, этакая попытка убедить разработчиков .NET, что лучше MSSQL никого нет. А MSSQL-щики и сами никуда не денутся - TSQL то не особо позволяет многого - сказали переходить на .NET, придется переходить на .NET. У нас например на ASA все проще - на WatcomSQL можно сделать все, для дотнета под новую VS 2005 помимо нативного ADO.NET драйвера еще добавят и SQL Anywhere Explorer, ничем не уступающий аналогичному под MSSQL. Так что зачем были сделаны эти дикие потуги обьединения 2-х разных продуктов, для решения разных задач - я совершенно не понимаю. Зато примерно представляю, в какой геммор все это может вылиться.
10 ноя 05, 08:00    [2053947]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Дикий Билл
Member

Откуда:
Сообщений: 9652
ASCRUS
А MSSQL-щики и сами никуда не денутся - TSQL то не особо позволяет многого - сказали переходить на .NET, придется переходить на .NET.
Столько обходились, а теперь вдруг придется...
10 ноя 05, 09:49    [2054180]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
nkulikov
Guest
Странно что пока нет сравнения насколько удобно неудобно писать на .Net с DB2...
Может я правда плохо искал...
10 ноя 05, 12:53    [2055374]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
Дикий Билл
ASCRUS
А MSSQL-щики и сами никуда не денутся - TSQL то не особо позволяет многого - сказали переходить на .NET, придется переходить на .NET.
Столько обходились, а теперь вдруг придется...


Обходились потому что не было альтернативы. А сейчас партия скажет: "надо", в смысле: "дот-нет", комсомол ответит: "есть!", и начнет дружно ваять сохраненки на .НЕТ-е. Шучу.
11 ноя 05, 06:12    [2058035]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
nkulikov
Guest
Единственное, что меня смущает в .Net хранимых процедурах.
Это что что вместо написания сложных, но эффектиеых запросов люди будут все делать в курсорах и ResulSeta-х. Работая с ними на манер клипера ....
11 ноя 05, 11:12    [2058894]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
На мой взгляд .Net - исключительно пригоден (и хорошо это делает) для компонентного программирования конечных приложений. Если я вдруг решу что мне нужно написать ХП на каком-то другом языке кроме SQL, то этим языком C# точно никогда не станет, потому как захочу получить максимум производительности при минимуме потребляемых ресурсов. ИМХО C# не предназначен для создания низкоуровневых и высокопроизводительных приложений.
11 ноя 05, 11:24    [2058983]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Dooma
Guest
c127
ИМХО серверная часть удобнее пишется на специально созданном языке сервера, типа PL/SQL
Та часть, которая непосредсвенно DML -несомненно. Так что не волнуйтесь про nested loop. Тем не менее, например, у меня есть н-ное количество ф-ций которые я точно переведу на .NET. Например ф-ция для печати перевода суммы в словесное представление куда гармоничнее будет выглядеть на C#, да и работать будет быстрее.
Тем более что хранится она будет на сервере, а отлаживать я ее буду на том же VS. Мне будет удобно, вам - не знаю.

c127
Это мелкософту так бы хотелось. Но на самом деле .НЕТ сопрягается без проблем со всем у кого есть .НЕТ драйвер, так что при выборе сервера лучше использовать более существенные соображения. Дешевле обойдется.
Да нет, это вам бы так не хотелось, но благодаря MS .NET все же лучще сопрягается с Yukon. Да и дешевле обойдется тот же Yukon, и уж тем более в обслуживании. А если имеются в виду расказы про то, как MSSQL не "потянет", а оракл "потянет", то приберегите их для своей бабушки :)
11 ноя 05, 12:08    [2059315]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Ц4
Guest
Dooma
но благодаря MS .NET все же лучще сопрягается с Yukon.


И в чём "лучшесть" ?
11 ноя 05, 12:41    [2059648]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
2 Dooma
механизм перевода суммы в пропись можно реализовать чистым SQL по идее, вместо массивов - справочники настроек по разным языкам.

---
Vae victis!
11 ноя 05, 12:55    [2059760]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить