You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Microsoft is now getting into the lightweight database game with SQL Server Data Services. It looks to follow a similar pattern to simpleDB and CouchDB with named, attribute pairs in a flat storage space and accessibility through REST. Some of the interesting things they are bringing to the game:
It looks like a great cloud based simple storage system with some of the goodness MSSQL bring to the table. They are now signing up BETA testers and we will be putting some demos together to show how Access can work with these lightweight database systems.
Sounds good, but I don't understand half the geek-speak used. What do the following mean:
• Lights-out manageability
• Novel distributed data fabric for massive scale out operation
• Geo-redundant data copies to ensure business continuity
• Query language supports the retrieval of complete entities
• Paging queries Yours sincerely, A mere Access programmer.
It's another non-relational sidetrack much like sharepoint. Not so much a theory as a whim!
Hmmm. As Alan points out above, the glyphs are indeed intriguing. Linguistically speaking, I don't
think we are looking at cannonical geek speak, but rather an emerging subdialect, NGFBBEVPNGDBA speak (Neo Geo Free BroadBand Enabled Virtual
Private Networked Geeky DataBase Administrator). However, I think I have succesfully deciphered it and what it really means is: "if you are on a budget of less than US$100,000 per project, then we (Microsoft) consider that you are not a developer but a power user and therefore we use this obscure dialect as a polite way of telling you to naff off and not waste our time. Anyone willing to spend US$100,000 or more on our new service is very welcome to phone us up and ask us what the heck we meant. However, be warned that we don't really know ourselves because we are not entirely sure how you might consider using this new service that we have developed. You see, this is how we do things, because our experience tell us that if you design something then someone will use it, but that there is no way for us to predict HOW they will use it. So, just as it is better to let Google provide our product documentation (we are a bit disappointed with Wikipedia.org), we let the development community decide what products we will continue to develop. This is a variation on a concept known as Variant Democracy and we are working on a suitable acronym, can you vote on VD? Anyway, this Variant Democracy thing is why we have produced so many new and often overlapping data access technologies in the last year, such as LINQ, Acropolis, SubSonic, DLINQ, etc, etc, etc. Only one will survive, but why should we invest our profits deciding which one is best? Anyway, we have to give all them developers that we have employed something to do, don't we? You never know, they might just reinvent Access. Talking of which, we really can't understand why folks just will NOT use Access as the power user's Excel. We have spent billions on Visual Studio, but them Power Users build some really good apps with Access. And then, to add insult to injury, they expect us to consider them developers." In reply to some of Alan's questions, here are a few approximations: . Provisioning
The Service actually provides something useful? . Lights-out manageability
We've got a couple of diesel generators in case the electricity goes down. If this takes off, we are commited to building our own Nuclear Power station? . Novel distributed data fabric for massive scale out operation
Instead of spending just US$100,000 on our new service, why don't you spend US$1,000,000? . Geo-redundant data copies to ensure business continuity
We do understand that not everyone lives in Redmond and that you just might not work for Microsoft. We have also been informed that there is
intelligent life in China, India and even the UK, although we have not yet established which state these towns are located in. . Query language supports the retrieval of complete entities
This sounds like LINQ speak with a dash of Data Entities Framework. I think it means you can get a whole table/data entity sent in one go, a bit like what an Access Back End does. . Paging queries
This is LINQ speak with a dash of Data Entities Framework. I think it means you can get a table/data entity sent in chunks. Wow! Access can't do this, where is my cheque book?
And I thought I was the only one on another planet...
Having worked with a client dabbling in this area for several months already, I'm pretty excited that MS has finally seen the light. Our "cloud" database-based application was up and running within a half-hour of the time I registered it, and fully operational within a couple of days after that. Nope, it's not based on Couchdb or Simpledb. We use Dabbledb. With one glaring exception, Dabbledb already has this stuff down pat as far as I'm concerned. If MS can deliver the whole package including security at the user level, they're going to be filling a niche that a lot of people aren't yet aware of. That's the hitch for MS, though. A lot of very smart people really do know all about this niche and are racing to fill it before MS gets there. Back to this MS entrant. Yeah, yeah, the jargon is still pretty self-absorbed and inward-looking. But for heaven's sake, they're still building the thing; give them a chance to catch their breath. Who knows, maybe one of these days someone over there in Redmond will figure out that they need to add an English-to-Geek translator to the staff. In the meantime, I strongly recommend that Access developers who really want to know where the future is going to lead us should take a long, close look at what's happening here.
Why can't Access fill(or be made to) this niche?
This in the cloud stuff is pretty important. At the moment you need to tackle it thru msxml (which is installed as part of vista) and easy to install for WinXP (if its not there already) Ryan will correct me. The big problem is a lack of samples. I will have an ACCESS article on MSxml and 37Signals coming out in April at http://vb123.com/news. Now you say why is it important, its important becuase it will allow you to have just few tables on the web to allow your customers to enter data from somewhere outside your local network. This can be grabbed from your all singing and dancing Rich Access database on the local network, alternatively the Rich db can post to the cloud table. What this doesnt do is make a your whole Access system net ready becuase coding is a lot trickier with the cloud systems as they bring data down 50 records at a time, not heaps of record like wonderful access forms. By the way if you sign up for my MaxOut newsletter you will get all this information from this blog and 5 other Access MVPs in a weekly newsletter Garry Robinson
Access Office MVP
There are many web applications that require a simple schema and massive scale. Sites like twitter.com that handles 50,000 requests a second and really is just handling simple self contained questions. Will Access developers be moving their databases to this kind of clouddb? I don't think so. But Access becomes a great way for the these sites to aggregate and report on the massive amount of data they receive. I know some of the terms on the sites are very technical....the basics are simple, secure, redundant and scalable database storage. How will this kind of database be used, we really don't know yet... but with MSFT and Amazon in the game you can bet solutions will start popping up and like any other data source (ODBC, OLEBD) Access will be able to integrate with it.
(don't know if you saw my first post on this in another topic...) Ryan, I'd love to see the database Clint came up with and compare it to the design I sent you guys. Send it on over --> dderobertis at d2stuff dot com. Thanks!