Все новости от 29 июня 2004 г.

Бета-версии Visual Studio и SQL Server на подходе

Софтверный гигант планирует также анонсировать недорогую редакцию Visual Studio в надежде расширить область применения своего флагманского инструмента программирования. Подробности станут известны на конференции Microsoft TechEd Europe, которая пройдет на этой неделе в Амстердаме.

Согласно веблогу команды разработчиков Microsoft Visual Studio, компания очень близка к завершению первой бета-версии Visual Studio 2005 с кодовым названием Whidbey и второй бета-версии SQL Server 2005 с кодовым названием Yukon. В марте Microsoft сообщила, что ей пришлось перенести на будущий год выпуск продуктов, которые первоначально планировалось запустить в производство в конце 2003 года. К этому сроку вышла только первая бета-версия Yukon.

Важным компонентом Visual Studio 2005 является инструмент моделирования, призванный усовершенствовать процесс введения в эксплуатацию в корпоративных центрах обработки данных вновь написанных бизнес-приложений. Новые средства моделирования, называемые Visual Studio Team System, должны стать продвинутой альтернативой хорошо зарекомендовавшему себя семейству инструментов IBM Rational, отмечает Майк Сакс, президент компании Sax Software, торгующей инструментами для платформы Microsoft.

Источники утверждают, что Microsoft выпустит еще одну редакцию Visual Studio, предназначенную для более широкого применения. Веб-сайт Neowin сообщает, что эта более дешевая редакция будет носить ярлык express. «Microsoft хочет уценить отдельные версии Visual Studio, чтобы ими могли воспользоваться даже любители, — говорит один информированный источник. — По-моему, идея заключается в том, что если разработчикам „нижнего звена“ предоставить технологию, они смогут вырасти и со временем станут игроками большой лиги».

Ожидается, что анонс более дешевой и упрощенной версии Visual Studio будет сделан на одной неделе с конференцией JavaOne, где Sun Microsystems планирует выставить инструмент программирования Java под названием Java Studio Creator за $99. 

 Предыдущие публикации:

 В продолжение темы:

Обсуждение и комментарии

	нц 29 Jun 2004 12:10 PM
Хммм.. на MSDN уже вроде давно лежит бэта вижуал студии 2005
	Пётр 29 Jun 2004 3:01 PM
ну, что осталось дождаться потоков от вечновыступающихпротив
	Lexx 29 Jun 2004 3:56 PM
"налетай не скупись покупай живопись!" ;) http://lab.msdn.microsoft.com/express 2Пётр: дождался ? :)
	СтранниК 30 Jun 2004 10:31 AM
Я просто плакал... Two Special Scalability Features There are two scalability features that are worth mentioning for very large database scenarios. Snapshot Isolation Level allows users to access the last committed row using a transitionally consistent view of the database. This new isolation level provides the following benefits: • Increased data availability for read-only applications. • Non-blocking read operations are allowed in an OLTP environment. • Automatic mandatory conflict detection for write transactions. • Simplified migration of applications from Oracle to SQL Server. For example, locking can cause blocks between applications that are reading and writing the same data simultaneously. If a transaction changes a row, then another transaction cannot read the row until the write commits. With SI, the reader can access the previous committed value of the row. === Очень похоже на имплиментацию rollback сегментов от Oracle. То есть до Ykon-а, писатель таки блокирует читателя. The second special scalability feature is table partitioning. While the concept of partitioning data across tables, databases and servers is not new to the world of databases, SQL Server Yukon provides a new infrastructure capability for partitioning of tables across filegroups in a database. Horizontal partitioning allows division of a table into smaller groupings based on a partitioning scheme. Table partitioning is designed for very large databases; hundreds of Gigabytes into Terabytes and beyond. Very large database (VLDB) query performance is improved with partitioning. By partitioning across a range of partitioning column values, subsets of data can be managed and reassigned to other tables quickly and efficiently. To learn more about Partitioning see SQL Server Books Online. === Ну наконец-то ребята из MS доросли до того чтобы признать что партицирование, а не partition view все же дает больше преймуществ. А я и не знал что в MSSQL при взаимоблокировках, разрешение конфликтов не обязательное?? Искренне рад, только все это за исключением Partition было в Oracle еще 6 версии примерно в 1994 году ( сейчас 10G), а партицирование было введено в 8 версии, то есть как минимум 6 лет назад.
	jstm 30 Jun 2004 12:43 PM
2 СтранниК Только похоже версионность в Юконе получше чем у Оракла сделана. Грубо - Юкон вроде хранит цепочку измененных записей a-la linked list и поиск версий занимает намного меньшее время чем перелопачивание блоков с нужным SCN в Оракле. Хотя, таки да, Oracle the Best!
	eXOR 30 Jun 2004 12:45 PM
2 СтранниК: SQL серверу до оракла как пешком до луны, но опять-таки цена ;-)...
	Yuri Abele 30 Jun 2004 12:48 PM
To eXOR: > SQL серверу до оракла как пешком до луны Ну не во всем. Скажем так, что это два пересекающихся множества. Хотя по совокупности, конечно Oracle впереди. Но SQL Server очень сильно догоняет
	СтранниК 30 Jun 2004 12:55 PM
2jstm 2 СтранниК Только похоже версионность в Юконе получше чем у Оракла сделана. Грубо - Юкон вроде хранит цепочку измененных записей a-la linked list и поиск версий занимает намного меньшее время чем перелопачивание блоков с нужным SCN в Оракле. === Я бы так не утверждал, до тех пор пока не выйдет реальный продукт. А то знаете теория теорией, а реализация может подвести.
	СтранниК 30 Jun 2004 12:59 PM
Yuri Abele Просто мы уже неоднократно обсуждали с господином PTO и он меня просто уверял, что MSSQL ну ни чуть не хуже, а когда вопрос заходил про блокировки настоятельно отсылал меня к документации, не желая уточнять, насчет того выполняется неблокируемое чтение в версиях MSSQL до Ykon-а. То есть до Ykon-а проблема с чтением данных которые были изменены есть и это факт, старательно умалчиваемый.
	СтранниК 30 Jun 2004 1:01 PM
2eXOR 2 СтранниК: SQL серверу до оракла как пешком до луны, но опять-таки цена ;-)... === Это уже другой вопрос. Я согласен, что Oracle стоит "безумно дорого" особенно Enterprise версии. Как вы думаете , если Oracle так дорого стоит, а его все равно берут, наверно чего-то у конкурентов не хватает?
	Yuri Abele 30 Jun 2004 1:15 PM
To СтранниК: > если Oracle так дорого стоит, а его все равно берут, > наверно чего-то у конкурентов не хватает Как говорят немцы "Jein!" - и да и нет - не стоит забывать про маркетинг и инерции мышления и рынка
	Yuri Abele 30 Jun 2004 1:18 PM
To СтранниК: > неблокируемое чтение в версиях MSSQL до Ykon-а Я может не совсем понял о чем речь, но возможность "грязного" чтения в SQLServer-к до Yukon есть
	СтранниК 30 Jun 2004 2:13 PM
Yuri Abele To СтранниК: > неблокируемое чтение в версиях MSSQL до Ykon-а Я может не совсем понял о чем речь, но возможность "грязного" чтения в SQLServer-к до Yukon есть === Постараюсь объяснить. Если запустилася запрос например в 10:00 и будет работать до 11:00( естественно интервал может быть разный) в силу тех или инных причин,а в туже самую таблицу постоянно поступают обновления, то запросу необходимо прочитать только те блоки которые были в БД на момент запуска запроса то есть к 10:00. То есть интересует данные в БД на момент 10:00. Но если строка которая попадет в отчет была изменена в период с 10:00 до 11:00 была изменена то эти данные уже не должны попасть в отчет. В Oracle это решается с помощью сегментов отката. То есть старый блок ( помещается в сегмент отката), а транзакции читатели строят их него для себя временной имидж БД на определенный момент. Чем больше размер сегментов отката, тем больше вероятность того что такие блоки будут найдены и тем больше гарантия того, что запрос будет выполнен. В 9i версии есть возможность использовать RETENTION_TIME - переиод времени в течение которого требуется хранить старые блоки( в основно это связано с доступных дисковым пространством ну и конечно необходимостью) Хочу подчеркнуть , что блоки в сегментах отката , не есть грязные блоки, это просто старая версия данных на определенный момент. То есть Oracle всегда работает с консистентым снимком БД на определенный момент времени. То же что есть в MSSQL -это просто возможность прочитать неподтвержденные данные данные в процессе их изменения, не подтвержденные сommit-ом. Как получить снимок БД на определенный момент в MSSQL я честно скажу не знаю.
	jstm 30 Jun 2004 3:40 PM
2 СтранниК Судя по всему в Юконе как-раз можно будет. Другой вопрос как ето будет работать
	А.Хохлов 30 Jun 2004 3:44 PM
2Странник Как получить снимок БД на определенный момент в MSSQL я честно скажу не знаю. А если для каждой таблицы создать дополнительную таблицу, в которую триггерами записывать все версии данных в основной таблицы + время и тип изменения. Читать ее в режиме nolock - это решит вопрос или нет?
	СтранниК 30 Jun 2004 5:30 PM
2А.Хохлов Это уже велосипед, мы так договоримся и свою СУБД написать. Не так ли? Тут много вопросов и много если.
	СтранниК 30 Jun 2004 5:34 PM
2jstm 2 СтранниК Судя по всему в Юконе как-раз можно будет. Другой вопрос как ето будет работать === Да, как и везде. В третьем релизе(сервис-паке) будет работать. А если фитчас сложная , то дводка может занять несколько версий продукта. Просто Oracle свою систему( а именно систему сегментов отката) уже подтачивает и подстраивает не меньше 10 лет, может Microsoft ему утрет нос, ну скажем за 3 года. Но первые релизы точно будут глюкать.
	А.Хохлов 30 Jun 2004 5:57 PM
2СтранниК Свою СУБД пожалуй писать не будем - даже если вдруг напишем, продать ее будет сложно. Но я имел ввиду несколько другое. Неблокирующее чтение - вещь безусловно хорошая, но скажем получить сегодня отчет по состоянию на вчера оно не поможет. Если же нужно только на сейчас - пусть сервер сделает все сам.
	jstm 30 Jun 2004 10:05 PM
2 А.Хохлов Flashback Query...
	СтранниК 1 Jul 2004 10:33 AM
2А.Хохлов Но я имел ввиду несколько другое. Неблокирующее чтение - вещь безусловно хорошая, но скажем получить сегодня отчет по состоянию на вчера оно не поможет. Если же нужно только на сейчас - пусть сервер сделает все сам. === Это не имеет значения на когда получать отчет. Для того чтобы получить корректный отчет на любое время требуется консистентная копия БД на текущий момент времени. То есть если я запускаю отчет "на вчера" сейчас, мне нужна консистентная копия БД( ну или просто таблиц по котором идет запрос) на момент запуска. Иначе по неконсистентной копии гарантировать что цифры в отчете правильные довольно трудно. То есть опрератор SELECT должен прочитать те блоки таблицы которые ему нужны по запросу, но с гарантией что состояние этих блоков соответсвует моменту запуска оператора. То есть данные для запроса не должны менятся в течение времени его выполнения, для этого запроса. Насчет пусть сервер делает все сам , я не против , только у Oracle пока это получается сделать лучше. Согласитесь эксклюзивная блокировка на таблицу не метод получения консистентных данные для отчета( может я не правильно выразился ?).
	А.Хохлов 1 Jul 2004 2:43 PM
2Странник По поводу вопросов и если. Думаю, что предложенная схема сработает, если все незавершенные транзакции начаты позже интересующего момента времени. Неясно, как определить этот факт. Так что неблокирующее консистентное чтение никогда не лишне...
	PTO - ptokgb.ru 6 Jul 2004 3:26 PM
2 СтранниК: как интересно, берете документ на 14 страницах, находите на нем 5 строк и рассказываете про то какой крутой Оракл... и что с того, что Оракл это умел делать 8-10 лет назад? про брокера, нотификейшн и репортинг вы конечно не заметили, так же как и еще про кучу других весьма полезных народу фич. Угу, снапшот изоляция похожа на то, что делает Оракл по результату действия... но по архитектуре требует сильно меньше рессурсов (мы вроде обсуждали уже как сие работает у Оракла?), при этом работают нормальные курсоры (как там в новом Оракле с курсорами? какие типы их есть?). И еще ответьте на несколько прямых вопросов: 1. сколько типов уровней изоляции транзакций предусмотрено стандартом SQL 92 2. сколько из типов из п.п.1 реализовано в SQL Server 3. аналогично для Oracle 4. может ли современная база, не поддерживающая стандартные уровни изоляции считаться серьезной корпоративной СУБД 5. отсутствие "ридер не блокирует райтера" является ли обязательным показателем серьезности корпоративной СУБД
	СтранниК 13 Jul 2004 10:01 AM
2PTO Извеняюсь за задержку ... отпуск знаете ли. По пунктам: 1. SQL92 defines four levels of isolation in terms of the phenomena a transaction running at a particular isolation level is permitted to experience Preventable Read Phenomena by Isolation Level ( Для удобства в случае нечитабельности разделитель ":" ) Isolation Level: Dirty Read:Nonrepeatable Read:Phantom Read Read uncommitted: Possible:Possible:Possible Read committed: Not possible:Possible:Possible Repeatable read: Not possible:Not possible:Possible Serializable: Not possible:Not possible:Not possible 2. Насколько помню вроде бы подерживал все уровни изоляции. 3. Oracle offers the read committed and serializable isolation levels, as well as a read-only mode that is not part of SQL92. Read committed is the default. Oracle Isolation Levels - Read committed - Serializable - Read-only 4. Это философский вопрос. Почему? Очень просто. Уровни изоляции это все? Наверно нет, есть еще много чего и насколько мне известно не один производитель СУБД не гарантирует 100% совместимость обычно SQL92 Entry. Вас наверно интересует почему Oracle не подерживает Dirty READ? 5. Знаете, может и не является пока с этим не столкнешься. Я бы сказал это из серии правил хорошего тона. Как мне объяснить директору например финансового департамента, что мол де у нас система онлайновая (типа несколько транзакций в секунду ), а он тут со своим отчетом ежедневным лезет. А для того чтобы получить корректные данные надо всех отрубить иначе отчета не получится. Знаете куда он меня пошлет? А если еще ему захочется получать все это в онлайне. P.S. Когда общаешся с производителем системы , классный костюм и красивые рекламные буклеты конечно впечатляют, но вот как только докапываешься до сути работы программного продукта, тут и начинается типа "да зачем это вам нужно" или "да мы уже доделаем в след. версии" ну и т.д.
	СтранниК 13 Jul 2004 10:19 AM
2PTO 2 СтранниК: как интересно, берете документ на 14 страницах, находите на нем 5 строк и рассказываете про то какой крутой Оракл... и что с того, что Оракл это умел делать 8-10 лет назад? про брокера, нотификейшн и репортинг вы конечно не заметили, так же как и еще про кучу других весьма полезных народу фич. === Да, пусть хоть за пивом бегает. Я интересуюсь фундаментом здания, а не спутниковыми антенами на крыше этого здания. А если фундамент слабоват, то как не размалевуй здание и как не крась все равно он сядет. То есть вы считаете в порядке вещей, что взамиоблокировка не детектится в MSSQL 2000? Не вы ли тут пели что СУБД практически не требует вмешательства DBA типа самонастраивающаяся система. Ну конечно, если проблемы решать перестартом, то наверно вы правы. И конечно отсутствие transitionally consistent view of the database это так пустяк? === Угу, снапшот изоляция похожа на то, что делает Оракл по результату действия... но по архитектуре требует сильно меньше рессурсов (мы вроде обсуждали уже как сие работает у Оракла?), === Курица еще в гнезде, вы уже "меньше ресурсов" Факты сэр?Это есть голословное утверждение. Да, мы с вами уже обсуждали сегменты отката, но вскользь.Я специально не стал эту тему развивать потому, что вы не понимаете как они работают. === при этом работают нормальные курсоры (как там в новом Оракле с курсорами? какие типы их есть?). === Да, все по страрому. Как было так осталось. Да, я еще помню как вы распространялись про то как это круто Partition view. А теперь глядь уже ваша любимая компания доросла до того чтобы признать, что этого не достаточно, и добавила нормальное партицирование в новую версию СУБД.
	СтранниК 23 Jul 2004 6:34 PM
Вот здесь все великолепно описано. Мне понравилось. http://www.rsdn.ru/article/db/yukonvers.xml#XSLTPART1411201 20
	zocor dosage - krez72usa.net 6 Sep 2006 3:17 PM
Hello, I need help http://kegga.ke.funpic.de/zocor-and-grapefruit.html http://kegga.ke.funpic.de/when-generic-zocor-patent.html http://kegga.ke.funpic.de/side-effects-of-the-drug-zocor.ht ml http://kegga.ke.funpic.de/zocor-liver-side-effects.html http://kegga.ke.funpic.de/generic-zocor.html http://kegga.ke.funpic.de/zocor-joint-pain.html <a href='http://kegga.ke.funpic.de/zocor-and-grapefruit.html' >zocor and grapefruit</a> <a href='http://kegga.ke.funpic.de/when-generic-zocor-patent.ht ml' >when generic zocor patent</a> <a href='http://kegga.ke.funpic.de/side-effects-of-the-drug-zoc or.html' >side effects of the drug zocor</a> <a href='http://kegga.ke.funpic.de/zocor-liver-side-effects.htm l' >zocor liver side effects</a> <a href='http://kegga.ke.funpic.de/generic-zocor.html' >generic zocor</a> <a href='http://kegga.ke.funpic.de/zocor-joint-pain.html' >zocor joint pain</a>