Visual Studio en SQL Server 2005 opnieuw uitgesteld

De release van de volgende generatie ontwikkeltools en databasetechnologie van Microsoft is opnieuw uitgesteld, zo is te lezen op Windows Network. Hierdoor zal de uiteindelijke release-datum van beide producten uitkomen in het eerste halfjaar van 2005. Tegelijk met de bekendmaking van de vertraging liet Microsoft weten dat er een extra beta-versie is toegevoegd aan de roadmap voor de producten. Ook liet het bedrijf weten wat de definitieve namen van de producten zullen zijn: Microsoft Visual Studio 2005 en Microsoft SQLServer 2005, zo is te lezen op eWeek.

Tot nu toe ging de nieuwste versie van Microsoft SQL Server 2005 door het leven onder de naam Yukon. Microsofts Visual Studio 2005 was tot voor kort alleen bekend onder de naam Whidbey. Tom Rizzo, productmanager van de nieuwe SQL Server, liet weten dat de vertraging noodzakelijk is om aan de hoge eisen te voldoen die de klanten van het bedrijf verwachten. Dat zowel de SQL Server als de ontwikkelomgeving tegelijk op de markt worden gebracht is volgens Rizzo gelegen in de intentie van Microsoft om 'de markt significant te veranderen'. De klanten willen zowel de nieuwste generatie databasetechnologie als de nieuwste techniek in ontwikkelomgevingen kunnen combineren wat dus een gelijktijdige release noodzakelijk maakt. Volgens Windows Networks zal als gevolg van de vertraging van Yukon en Whidbey Windows Longhorn niet eerder dan 2006 op de markt verschijnen.

Reacties (47)

[Verwijderd]

(...) de nieuwste generatie databasetechnologie (...)

buzz-word alert! Relationele databases behoren niet tot de 'nieuwste generatie'; object-databases zijn van een nieuwere generatie en kunnen veel meer data aan dan welke relationele db dan ook.

[ACM]

Daarnaast: volgens mij zijn er nog niet zo heel erg veel ODMBS'en, en al helemaal geen die zich kunnen meten met SQLserver en de andere grote RDBMS'en...

Hoeveel echt bekende RDBMS'en ken je? Stuk of 10? 20?

Met een beetje google-en vindt je ook wel net zoveel ODBMS'en
En wat moet een ODBMS kunnen om zich te meten met SQLServer, zeker SQL kunnen spreken of via ODBC werken?
Zoals de vraag al impliceert, de toepassingen waar een ODBMS beter is dan een RDBMS en vice versa verschillen nogal. Ondanks dat is het principe van een ODBMS wel degelijk langgetest en snel.

terwijl de data zelf volgens de tot nu toe bewezen 'veiliger' methodiek "relationaliteit"

Waarom is dat nou weer bewezen veiliger
En zo dood zijn ODBMS'en nou ook weer niet, ze worden alleen minder gebruikt en/of minder vaak publiek getoond kwa toepassingen. Als je bij een grote ODBMS-bouwer in op de sites kijkt zie je best grote klanten voorbij komen. Als eerste voorbeeld dat ik wist te vinden: http://www.objectstore.net/our_customers/index.ssp
Shell, Siemens, e.a. zijn toch niet heel klein

[Verwijderd]

En wat moet een ODBMS kunnen om zich te meten met SQLServer, zeker SQL kunnen spreken of via ODBC werken?

een marktaandeel hebben die uit twee cijfers bestaat.. bijvoorbeeld 11%...

Ondanks dat is het principe van een ODBMS wel degelijk langgetest en snel.

die test hebben er naartoe gelijd dat de laatste jaren toch RDBMS de meest gebruikte is. vooral als het om kritisch gegevens gaat..

Waarom is dat nou weer bewezen veiliger

bij een RDBMS gebruik je eigenlijk een soort 'remoting' om je gegevens te krijgen. onafhankelijk van je programmeer/ontwikkelomgevings is je informatie opgeslagen. bij ODBMS krijg je de neiging om de gegevens en ontwikkelomgeving nog dichter bij elkaar te brengen, wat negatief kan werken. in SQL server 2005 wordt het heel mooi opgelost: je kjan een optionle laag definieren van classes die de tabellen beschrijven/object. zo kan je gebruik maken van object als je dat wil, maar onafhankelijk daarvan heb je je data altijd op de oude goede manier nog erin staan.

als ik nu voor een DB kies, doe mij dan maar een RDBMS, die kan tenminste de komdende 5 jaar nog gebruiken, terwijl de toekomst van een ODBMS nog steeds ter discussie staat.. noem me anders wat voordelen van je ODBMS?

OODBMS zijn er nog niet klaar voor, en ik denk dat ze er nooit klaar voor zullen zijn.. het is waarschijnlijker dat een deel van de OO-snufjes naar een RDMS verhuizen, zoals bij yukon het geval is.. voor veel mensen is het belanrgijk om de data en de ontwikkelomgeving te scheiden..

[ACM]

Goed, voorbeeldje dan:

Stel je hebt een (diepe) boom van veel nodes, bijvoorbeeld de beschrijving van onderdelen van componenten, die weer subonderdelen hebben etc etc.
Hoe ga je die boom modeleren in je RDBMS? Ik wens je veel sterkte en verwacht eerder klaar te zijn met een flexibeler systeem in een ODBMS
Goed, het modeleren is nog wel te doen, maar je relationele integriteitsbewaking? Het snel en efficient querien van die gegevens?
Een boom in SQL bewaren en bijgewerkt houden is een rotwerk, het simpele "bij elk child een parentid opslaan" is een recursief rotwerk kwa selectie en de andere oplossingen (nested set, nested interval, materialized path, e.a. (?)) zijn zeer bewerkelijk met (eenvoudige) bewerkingen op die boom.

[EfBe]

die test hebben er naartoe gelijd dat de laatste jaren toch RDBMS de meest gebruikte is. vooral als het om kritisch gegevens gaat..

Dat heeft niets met elkaar te maken. Het relationele model is handiger wanneer je dicht op de database zit te programmeren. Veel oude apps doen dat. Een object database is niet interessant wanneer je niet in een OO taal het ding kunt benaderen, wat pas de laatste paar jaar in gang is gezet.

bij een RDBMS gebruik je eigenlijk een soort 'remoting' om je gegevens te krijgen. onafhankelijk van je programmeer/ontwikkelomgevings is je informatie opgeslagen. bij ODBMS krijg je de neiging om de gegevens en ontwikkelomgeving nog dichter bij elkaar te brengen, wat negatief kan werken.

Wat een kolder. Lees eens een artikel van dr. Peter Chen over entities, stamt uit eind jaren 70. Zolang je concepten en uitvoering scheidt is er niets aan de hand. Hoeveel mensen bouwen stored procedures met daarin een deel BL ? Juist, heel veel. Wat zei je ookalweer over de handel dicht bij elkaar te brengen?

in SQL server 2005 wordt het heel mooi opgelost: je kjan een optionle laag definieren van classes die de tabellen beschrijven/object. zo kan je gebruik maken van object als je dat wil, maar onafhankelijk daarvan heb je je data altijd op de oude goede manier nog erin staan.

Nee zo werkt het helemaal niet en zo werken object databases ook niet. Bij relationele databases heb je data-less entity definities (al dan niet real time zoals in een select resultset), of beter: tuples. Die definities vormen de basis voor de data die gerelateerd is aan elkaar middels die definities. Bij een object database heb je die relaties niet per definitie, maar per instance. Wezenlijk verschil.

In Yukon is dat absoluut niet te definieren anders dan op de slappe manier van het verwijderen van de FK constraints en dan per instance relaties leggen middels waarden overkopieren, maar zo hou je geen integrity checks meer over.

als ik nu voor een DB kies, doe mij dan maar een RDBMS, die kan tenminste de komdende 5 jaar nog gebruiken, terwijl de toekomst van een ODBMS nog steeds ter discussie staat.. noem me anders wat voordelen van je ODBMS?

Ga maar eens een inheritance tree van classes die moeten worden weggeschreven in een database modelleren in een abstract relationeel model. Lukt niet! (nee dat lukt ECHT niet, kom niet aan met slappe truukjes om inheritance te mappen op table constructies want die zijn geen van alle integrity safe) En daarom werken Object databases beter in een oo omgeving dan relationele databases.

OODBMS zijn er nog niet klaar voor, en ik denk dat ze er nooit klaar voor zullen zijn.. het is waarschijnlijker dat een deel van de OO-snufjes naar een RDMS verhuizen, zoals bij yukon het geval is.. voor veel mensen is het belanrgijk om de data en de ontwikkelomgeving te scheiden..

Die laatste zin impliceert dat je juist geen C# achtige zaken in de database zou willen.

Verder is het verhuizen van 'wat' snufjes onzin. het is OF full support OF niet. Oracle 9i kan al jaren wat Yukon pretendeert te gaan doen. Db2 kan al jaren stored procs aan in weet ik hoeveel talen, waaronder Java. Zie je veel mensen dat gebruiken? Nee. Is het dan ineens wel belangrijk wanneer Yukon dat gaat doen? Nee in het geheel niet.

[garagaholic]

Het gaat vast niet om de achterliggende methodieken

Daarnaast: volgens mij zijn er nog niet zo heel erg veel ODMBS'en, en al helemaal geen die zich kunnen meten met SQLserver en de andere grote RDBMS'en...

Ik heb in ieder geval nog nooit van zo iets gehoord

[EfBe]

Yukon is GEEN Object database maar een gewone relational database.

Iedereen die denkt dat Yukon een object database is komt bedrogen uit.

[Verwijderd]

Ik heb in ieder geval nog nooit van zo iets gehoord

http://www.service-architecture.com/object-oriented-databases/articles /odbms_faq.html#Can%20ODBMSs%20handle%20large%20databases?

Nu wel.

[Verwijderd]

Object-Databases zijn nu al half gesneuveld.. er is nog steeds geen 1 grote applicatie wat erop draait. alleen de hobbiestische-bedrijven doen er wat mee. RDBMS zijn getoets en hebben zich kunnen bewijzen in de markt. bovendien kan je met SQL server 2005 in C# bijvoorbeeld wat dingen in de DB zelf defineren: krachtigere Stored-Procedures.. waardoor je de DAL van je programma voor een deel kan verschuiven naar de DB die veel beter geoptimaliseerd is voor de omgang met dit soort gegevens. dus een tintje code/object in je DB, terwijl de data zelf volgens de tot nu toe bewezen 'veiliger' methodiek "relationaliteit".. en als object spaces bij kotm kijken (een toevoeging onderdeel van .NEt 2, wordt het helemaal een feest) ...

2005 wordt een veelbelovend jaar voor de .NET'ters

[EfBe]

Object-Databases zijn nu al half gesneuveld.. er is nog steeds geen 1 grote applicatie wat erop draait.

Onee? En hoe weet jij dat zo zeker?

alleen de hobbiestische-bedrijven doen er wat mee. RDBMS zijn getoets en hebben zich kunnen bewijzen in de markt. bovendien kan je met SQL server 2005 in C# bijvoorbeeld wat dingen in de DB zelf defineren: krachtigere Stored-Procedures.. waardoor je de DAL van je programma voor een deel kan verschuiven naar de DB die veel beter geoptimaliseerd is voor de omgang met dit soort gegevens. dus een tintje code/object in je DB, terwijl de data zelf volgens de tot nu toe bewezen 'veiliger' methodiek "relationaliteit"..

Als je ECHT diep nadenkt over relationele modellen dan weet je dat OO daar geen moer mee te maken heeft en ook niet daarmee mixt.

C# is absoluut ongeschikt voor het bouwen van goede relationele expressies. Dit komt omdat C# geen set-based taal is, itt SQL. Dat 'krachtiger' van je is m.i. pure marketing blabla, net zoals dat beter geoptimaliseerd zijn voor 'dat soort gegevens'. Wat bedoel je te zeggen? Dat code die resultsets verwerkt beter draait IN een database ipv erbuiten? En waarom zou dat zijn?

en als object spaces bij kotm kijken (een toevoeging onderdeel van .NEt 2, wordt het helemaal een feest) ...

O/R mapping is nu al mogelijk, daar heb je objectspaces niet voor nodig en al helemaal Yukon niet.

[Verwijderd]

ik gebruik nu een O/R-mapper

[EfBe]

Da's mooi. De mijne toevallig?

[Verwijderd]

DUDE:
Frans Bouma? je naam eerder gezien op ASP.net forum.. ik ben entitybroker aan het testen
van Thona dus.. maar ik ga de jouwe binnenkort uitproberen... ben nu lekkere aan het afstuderen, er komt een hoofdstk in me eindverskag over O/R-mapping, dus misschien komt de jouwe ook aan bod

[Verwijderd]

Please check your sources:
http://www.service-architecture.com/object-oriented-databases/articles /odbms_faq.html#Can%20ODBMSs%20handle%20large%20databases?

Probeer jij maar eens 500 terabyte (geen typo) op te slaan in een Oracle of een SQL server.

[ACM]

Volgens de eigen site van slac is ie nu zelfs 895TB... Die 500 TB is een getal van 2002.

[Verwijderd]

895TB. Nog effe en de exabyte notatie is nodig.

In 1999 was het nog 'maar' 25TB.

[MarcieMars]

Ik heb wel een idee voor een tussenrelease; WinXP en Win2K3 voor AMD64 instructieset! Nu Intel deze instructieset ook ondersteunt, is dat een mooie tussenstap. Hoeven ze Longhorn, Yukon en Whidbey wat mij betreft alleen voor de 64 bits omgeving uit te brengen...

[Access]

Microsoft werkt al een tijd aan een X86-64 versie van Windows XP. Zie ook de onderstaande links:

Windows XP 64-Bit preview en Athlon 64-benchmarks
Bèta-versie Windows XP 64-bit Edition beschikbaar
Meer Athlon 64-scores met bèta Windows XP 64-bit Edition

Voor Windows 2003 Server geldt hetzelfde. Daar is ook al een X86-64 beta release voor.

[Verwijderd]

Zie geen toegevoegde waarde voor XP om een 64 bit extensie te verkrijgen, voor de performance hoeft het niet direkt. En adresseringen van meer dan 2Gb etc is voor de gemiddelde thuisgebruiker ook geen direkte noodzaak.

Mischien marketing technisch wel interesant, maar vermoed dat de meeste bedrijfen en ook particulieren op dit moment geen 64-bit spul in gebruik zullen hebben.

[sus]

Ik werk @ Dynabyte, en merk daar dat de amd64 vrij goed verkoopt. Beter dan ik zelf had verwacht eigenlijk. Zeker omdat er nog helemaal geen 64-bits OS op wordt geleverd, en ook andere apps nog niet veel in 64-bits te verkrijgen zijn.

Een XP-64 zou daar dus zeker wel op zijn plaats zijn, om toch gebruik te _kunnen_ maken van de mogelijkheden die de processor biedt.

[mbrb]

Dit wordt zo langzamerhand pijnlijk voor al die figuren die zijn overgestapt op een subscription voor Microsoft spullen.

Heb je voor jaarlijks 30% van de nieuwprijs een contract gesloten, levert Microsoft vervolgens niks uit (Longhorn, SQL server, vs). Feitelijk betaal je dus voor niets. .

Ga dat als IT'er maar eens uitleggen aan je baas die in verband met bezuinigingen flink aan het zoeken is......

[Verwijderd]

jou begrijp ik dus niet.. als je het eerder maar wel buggie had gekregen, dan zat je nu harder te zeuren..

en bovendien krijg je met zo''n "subscription voor Microsoft spullen" toch de huidige beschikbare software?? dus je kan nog wel een tijdje daarmee werken. en voordat je je ging inschirjven, had microsoft je niks beloofd kwa release data, dus wat is het probleem ??

bovendien kan ik me niet voorstellen dat je in de tussen tijd niet kan werken, omdat er iets ontbreekt aan de huidige visual studio (2003). anderen krijgen het ook voor elkaar om nu leuke appies mee te maken, moet je het dus ook kunnen anders ligt het eerder aan jou kennis.. of je koopt leuk wat third party sortware voor de tussentijd

[EfBe]

jou begrijp ik dus niet.. als je het eerder maar wel buggie had gekregen, dan zat je nu harder te zeuren..

Je snapt het niet: MS fixt geen bugs in vs.net 2003, jij moet dus tot medio 2005 wachten op de bugfixes. En dat terwijl Yukon de delay veroorzaakt, niet whidbey. Whidbey is nl. al vergevorderd.

bovendien kan ik me niet voorstellen dat je in de tussen tijd niet kan werken, omdat er iets ontbreekt aan de huidige visual studio (2003). anderen krijgen het ook voor elkaar om nu leuke appies mee te maken, moet je het dus ook kunnen anders ligt het eerder aan jou kennis.. of je koopt leuk wat third party sortware voor de tussentijd

Jij doet geen prof. ASP.NET development begrijp ik? Of serieuze software development met vs.net 2003? Ooit een solution met 10 projects of meer geladen en bv tegen inmense bugs aangelopen mbt assembly locks, controls die van je form verdwijnen ivm een failed compile etc. ?

En dat vind jij kwaliteit waar je mee kunt werken? VS.NET 2003 is in april een JAAR oud. Geen bugfix in zicht, maar wel hard nodig. Maar goed, zolang MS decipelen zoals jij allerlei onzin laat verkondigen komt het allemaal wel goed, toch?

En ja, ik doe alleen maar .NET development, en JA op hoog niveau en JA al heel lang en JA ik weet waarover ik praat.

[Verwijderd]

en ja, lees de posts hierboven .. er komen bugfixes voor VS 2003 als winxp SP2 komt..

http://www.microsoft-watch.com/article2/0,1995,1541195,00.asp

[EfBe]

Ik hoop het van harte maar ik denk dat dit service pack (wat overigens ook pas erg laat in 2004 komt) puur incompatibilities fixed mbt xp sp2.

[spoonman]

Ik werk ook iedere dag in VS.Net 2003 (asp.net en windows forms). Er zitten idd wel een aantal bugs in, maar er valt zeker mee te leven (het kan veel erger)

En zelf zeggen dat je op hoog niveau zit draagt weinig bij aan je geloofwaardigheid.

[Verwijderd]

Je hebt blijkbaar niet met de whidbey beta gewerkt. Dan lijkt vs 2003 opeens heel erg stabiel.

Laten we hopen dat MS erin slaagt om vs 2005 enigszins in de buurt van vs 6 te laten komen qua stabiliteit, anders ben ik bang dat ik toch maar eens een Borland .net product moet gaan uitproberen.

[Verwijderd]

ik geef toe, het kan wel beter met de VS2003, maar het totale beeld is niet zo slecht zoals jij het voorsteld.. ik bedoel.. kom nou: een beetje bugs zitten er altijd in een beetje grote applicatie..

en de bugs zijn eigenlijk ebdoeld om VS2003/2002 en de .net framework te laten werken met de SP2 voor een deel (niet alles is opgelost).. maar laat ik het zo zeggen: je kan het nog even doen met de Vs2003 tot volgend jaar..

het is niet zo dat ik alleen PRO microsoft ben, maar ik kan me voorstellen dat ze niet iedereen blij kunnen maken .. dat is nou microsoft, en als je VS2003 ECHT niks vind, neem een ander ontwikkelomgeving.. maar zoals ik zei, ik heb respect voor je mening, soms is het werken met VS geen pretje

[Verwijderd]

Licensing 6 is geintroduceerd in 2002. Alle klanten die een subscription hebben afgesloten hebben 3 jaar recht op upgrades, dus ook de SQL 2005 en Visual Studio 2005 producten (en Longhorn als dat in 2005 uitkomt)...

[Verwijderd]

En Office 2003?

[desmond]

OUCH! Ik zit met smart op betere schaalbaarheid van SQL 2k te wachten! De db groeit met ruim 30GB per maand..

[Verwijderd]

Volgens mij is er geen enkel probleem met de schaalbaarheid van SQL:
http://www.microsoft.com/sql/evaluation/casestudies/scalability.asp

[Verwijderd]

Iedereen die dit 'inzichtvol' heeft gemod moet eens de link volgen en de case studies van de large data eens goed lezen. Er wordt hier en daar met terabytes gegooid, terwijl er a) of niet bij staat dat al die data in SQL server staat, b) of expliciet bij staat dat de data in een andere database staat.

yep: vooral de reclame folders van de fabrikant geloven en zeker niet de verhalen van gebruikers zaols desmond.

Ik heb nog een paar fantastische stukken ontwikkelingsland te koop voor je in de VS. Gaat het echt helemaal worden.

[Database freak]

Verklaar je nader; SQL Server 2000 64-bit schaalt al behoorlijk ver en dat is voor een 4 jaar oude versie. Yukon zal dit sterk verbeteren.

[Verwijderd]

Okee: case studie ASB bank: data staat in Oracle; Disco: data in verschillende dbs-en; Rosetta: data in een IRI (?) mainframe db.

Dit is voor mij een geval van pronken met andermans veren: "SQL server is heel goed schaalbaar, kijk maar eens wat deze klant met Oracle kan."

Of SQL server zo goed schaalbaar is is zeker niet af te leiden uit deze case studies.

[napel25]

De ervaring van desmond is mijn ervaring ook wel een beetje. Je kan heel veel data opslaan in een SQL Server database, maar dan moet je er niet te veel mee willen doen. Wanneer je die data dan ook in een hoog tempo wilt kunnen wijzigen, moet je toch al gauw naar Oracle.

[Database freak]

Gek eigenlijk want een eerste Beta van Yukon was najaar 2003 (tijdens devcon) al uitgedeeld. Hierna zoud er niet meer aan features ontwikkeld worden enkel de bugs er uit halen.
MS wil blijkbaar wat dat laatste betreft en de beveiligin van de DB alles op alles zetten en neemt de release date uitloop voor lief (in eerste instantie zou Yukon ergens in 2003 uitkomen).

[bitflusher]

roadmaps zijn ook maar richtlijnen

[JeroenB]

Maar dingen die naar achteren worden geduwd komen zelden eerder uit

Het is sowieso te verwachten dat zulke dingen blijven vertragen als je erop uit bent om zulke gigantische produkten *tegelijk* uit te brengen. De synchronisatie tussen allerlei teams die daarvoor nodig is is vrijwel niet te overzien.

Verder is het nog een slechte zet ook: VS.NET 2003 (de huidige versie) bevat erg veel bugs (ik werk er de hele dag mee) en nu moet ik dus nog ruim een jaar wachten naar alle waarschijnlijkheid, omdat MS het nodig vindt om iedereen te pogen over te halen ook weer een SQLServer-licentie te kopen omdat dat zo goed bij elkaar gaat aansluiten. Ik wil van die bugs af en ik heb SQL2005 helemaal niet nodig!

[Verwijderd]

Gelukkig komt er tegelijk met WinXP sp2 ook een sp voor Visual Studio 2003 en .Net framework 1.1.

http://www.microsoft-watch.com/article2/0,1995,1541195,00.asp

[JeroenB]

Dat artikel doet vermoeden dat het alleen een patch is om compatible te zijn, niet de berg fixes waarop ik zit te wachten. Maar wie weet

[GBits]

Een beetje developer heeft MSDN Universal, zit SQL ook in.

[flab007]

een beetje developer in dienst van een groot bedrijf bedoel je zeker? Ik zie een freelancer of een devver in het MKB echt niet universal aanschaffen hoor!

[mindcrash]

Tenzij de firma in kwestie een Microsoft Gold partner is. Die krijgen namelijk een Universal account voor nop

[Verwijderd]

Ik heb tijdens de devdays (eind januari) al gehoord dat het nog een jaar zou duren tot Whidbey uitkomt. Wat was dan de oorspronkelijke planning?

[Verwijderd]

Ik vind het verstandig dat ze wachten.
Kunnen ze beter testen en de nu een betere versie uitleveren.
Denk dat door MS te weinig getest word hier en daar.

Ben heel benieuwd hoe het eindresultaat word.

Misschien kan het echt de concurrentie aan met Oracle.