Expert to Expert: Erik Meijer and Bart De Smet - LINQ-to-Anything
Play Dave Campbell: Inside SQL Services
Description
Technical Fellow Dave Campbell digs into the "fabric" of Azure's SQL Services. What are the current capabilities of SQL Services and how will they evolve? Can you upload stored procedures to the cloud and expect them to run? What does extending a shrink-wrapped
application to the world of distributed cloud services really mean? Listen in. Learn.
Download
Download this episode
- High Quality MP4 (368.9 MB)
- Mid Quality MP4 (257.8 MB)
- High Quality WMV (556.2 MB)
- MP3 (14.2 MB)
- Low Quality MP4 (100.8 MB)
- Mid Quality WMV (112.8 MB)
- WMV (228.0 B)
More episodes in this series
Dharma Shukla: Inside Live Framework
Related episodes
Episode 9 - Design for Manageability
Episode 8 - Design for Availability
Episode 7 - Design for Scalability
Episode 6 - Design for Data
Episode 5 - Platform and Connectivity Patterns
Episode 4 - Design for Operations
Episode 3 - Scalability and Deployment
Episode 2 - FailSafe Core Concepts, Part II
Episode 1 - FailSafe Core Concepts, Part I
The Cloud and the Whiteboard
The Discussion
-
vesuvius Charles please slow down with the posts, I can't cope. Especially if there is goldust by the most venerable Technical Fellows.
I feel like a kid in a sweet shop at the moment, completely hysterical!
-
Charles 
Much more to come (but I can't tell what it's about or who's being interviewed).
Keep on watching and listening. Of course, please talk back. We need you feedback. So, what do think of Azure? How will you innovate on it?
C -
Atachi Am I the only one who, when he talked about the underlying filesystem, instantly thought that it sounds kinda "WinFS-ish"?
(just minus the metadata stuff) -
sokhaty Too bad it's called SQL Services.
If it's not a SQL Server (which is presumably a good thing), it would make sense to drop the SQL moniker all together and name it something like Cloud Database Services. If it does offer a SQL query interface, that's fine, but it doesn't mean that SQL should be part of the name.
If it offered a solid relational calculus DSL and no SQL support, no one would complain.
As soon as you guys are building a new database service, why don't you take it a bit further and allow defining entities and relations between them as predicates in a semi-natural language? Relvars are predicates, according to the relational database theory. Why not to preserve the relvar's original meaning in the database metadata? That would be a competitive advantage.
PS: What's that S-LINK thing, anyways? Is it a subset of LINK or a superset of thereof? -
Peter Thomas Kudos to the SDS team for releasing Ruby implementations for SQL Services. For the rest of us!http://www.azurejournal.com/2008/10/ruby-and-sql-data-services-sdk/" target="_self">http://www.azurejournal.com/2008/10/ruby-and-sql-data-services-sdk-PT.