+972 52-548-6969
Embracing RavenDB
In fact, for over 30 years or so, the Database Wars have been settled, the relational databases have won the fight, and the decision left was which relational database to use. Everyone “knows” that NoSQL is something that Google invented to handle the amount of data and users they have, and that is it somehow related to scaling to Google or Facebook levels.
And since most of us aren’t working on applications that have millions of users, we get to keep using the tried and true methods, no need to bother with something that is only relevant at extreme high scale. The relational database has served us well, and can continue serving us in the future. Learning SQL was a very smart investment, after all.
Let us go back a bit to those Database Wars that I mentioned. In the 70s there were actually quite a lot of different types of databases competing with each other, anything from ISAM to DBase to relational databases. And as you can see, the relational database has won such a decisive victory that it rules undisputed for over a generation.
But one thing that we have to remember is that those Database Wars were fought on a drastically different ground than the one we have today.
1980 vs. 2012
In 1980, a 10 MB hard disk (that is in megabytes, about 2 songs or 3 pictures) cost around 4,000 $ US. Adjusting for inflation, that comes at about 11,000 $ US in today’s dollars. Just to compare, today a 10 MB of disk space would cost you about half a dollar cent. And those aren’t the only changes, of course. Computation speed, memory sizes and networks are all many orders of magnitude faster and cheaper than they were in the 80s.
Even more interesting is the differences in the type of applications being built. In the 80s, a typical application had exactly one user. Multi users’ applications had to support… 3 users. All of them at the same time! The UI paradigms were drastically different, as well. At the time, the master – details form was the top of the hill, the uncontested king of good UI design. But today… there are usually so many items and active elements on a single web page today as there were in entire applications then.
Why the history lesson, you ask? Why, to give you some perspective on the design choices that led to the victory of the relational databases. Space was at a premium, the interaction between the user and the application closely modeled the physical layout of the data in the database. That made sense, because there really were no other alternatives given the environment that existed at the time.
That environment is no longer here, and the tradeoffs made when 30 MB would cost as much as an annual salary are no longer relevant. In particular, one immensely annoying aspect of relational database is very much a problem today. Relational databases trade off read speed in favor of write speed. Because it made perfect sense to make this trade off when disk space was so costly, and making users wait an extra second was no big deal.
In separate studies conducted by both Google and Amazon, they found that even additional 100ms added to the latency of a page severely impacted their bottom line. And yet relational database tradeoff read speed (having to do joins and extra loads) for write speed (having to write small amount of data).
Another problem that pops up frequently with relational database is their inability to handle complex data types, such as collections or nested objects. Oh, you can certainly map that to a relational database, but that requires additional tables, and each additional table is going to make it that much more complex to query the data, work with it and display it to the user.
For many years, I have been working with customers on optimizing their applications using relational databases, and I’ve seen the same problems occur over and over again. That led me to the belief that the NoSQL databases aren’t suitable just for extremely scalable scenarios. NoSQL databases make sense for a wide range of options, and this realization led me to RavenDB.
In my company, we are using RavenDB as the backend database for everything from a blog, our ordering and purchasing systems, the daily build server and many more.
The major advantages that we found weren’t the ability to scale (although that exists), it is the freedom that it gives us in terms of modeling our data and changing our minds.
Comments
Every day I read same posts about nosql. But i've never seen samples of declared advantages. And what about disadvantages? Why people still use SQL Databases?
I saw webcast about stackoverflow modelling and RavenDB works incorrect about 3 times during webcast. I saw NoSQL is often unreliable and low-performance solution
Ayende,
I think you are right. However, I think there is something that developers must be advised when embracing RavenDb or another NoSql solution: the modeling mindset is different. When I tried RavenDb, my first mistake was to model using the same techniques when in the relational world. We have been using this techniques for many years, and the natural language is formatted to a speech about entitiies and relations
"A Customer belongs to a Company. A Customer has Orders. An Order Has a Product. A Product Has a Category. etc."
In the past we have been obsessed to the OLTP systems and data normalisation. Whenever modeling a new problem, I have many doubts what is the best model using a NoSql db. Maybe it is a matter of time and experience.
Congratulations. RavenDb is a great product.
"Why people still use SQL Databases?"
because they know how to make them work. Because it is ancient wisdom passed over generations. Because most people must be suffering really badly before they'd change anything.
If that was a rethorical question implying "Because they are better", I refute your rethorics on basis of empirical evidence of how humans make their choices in life.
Another point that I see as a problem for relational databases nowadays is the programming paradigm. When people developed procedural code, thinking in data as relations was an easy step. Today, we are always trying to bring the real model to our domain, so data and it's relationships aren't no longer as simply as relations. In many cases, a relational approach to a OO domain may break some concepts.
@bfcamara - I agree with your points. I have had the same problems while modelling a domain to NoSql database.
For example: A User has Roles, a Role as Permissions
With relational database, the modelling is simple - each entity becomes a seperate table, and foreign keys handle whether is is 1:1, 1:n or n:n relation
With NoSQL database, the answer comes back as - "It depends. Are you going to access Permissions in isolation of the Role?" And I end up thinking - Ummm ... I dont know, maybe yes, maybe no. I do not have spec for what this database will be used for. So maybe I should design it for maximum flexibility and store each entity in a seperate collection. In other words, I end up with relational database design for a No Sql database.
I need help!
Friends, I agree with you. Change to NoSQL is a breaking paradigm. As you've said, we are used to thinking about ER mapping, not Document mapping. I believe NoSQL people should invest more in sharing knowledge about "how to change your ER models to NoSQL ones". Ayende, I know you are a busy man, but, why not create a "mini-course" about "moving a traditional NH application to RavenDB" ? Maybe it could run as a post series or even a paid course in Tekpub.
I believe this would increase NoSQL embracing.
Well, 0.5 $ for 10 MB of HDD? Today I have found on eBay a 2TB disc for only 130$ - it is less then 0.001 $ for 10 MB.
Am I crazy or is this a rerun of on old post?
@Paulo Quicoli totally agree with you...
I'm very interested in NoSQL and in particular RavenDB, but it's been a little hard to wrap my head around it after so long dealing with relational databases. In particular I can get the very basic usage of, say, RavenDB, but it breaks down when I have to model actual relationships because I'm so used to the relational model and having to worry about keys.
Also, all of the Raven tutorials I've seen typically touch on a single "table" without going into the real world scenario of many different entities that are related in various ways. The whole index thing in Raven seems a bit complex if you have to manage it solely in the code, but maybe that's just being a neophyte.
Puneet, With RavenDB, the major role for modeling is finding the transaction boundary. Things that change together should be in the same doc. Starting out with each entity in a different collection is probably a bad thing. I would usually have Users -> Roles (permissions embedded inside the role).
gdn, A mistake, it is half a cent, not half a dollar. Fixed now.
Ronnie, It is a post that showed up for 5 minutes, then was pushed back.
I remember this post from a while back. I saw it in my rss feed and wanted to link it to my brother. When I went to link it, it was gone. Glad to see it is back.
the modeling disconnect is that nosql data is not normalized. for example the idea that a customer has orders order have a product and products have a category isn't really accurate. different data is required depending on the context in which the entity is used.
for example, load products into the catalog, the product would be an entity. it would have a category. but in the context of an order or shopping cart the product is a value object: description, price, and maybe an ID if you need to link back to the entity itself.
with nosql modeling there are no relations. there are aggregates. there is duplicate data and that is acceptable.
I guess what throws me for a loop is that it seems like with a NoSQL database you stuff objects inside objects inside other objects, and that feels "bad" somehow. I mean instead of a Customer that has Quotes and the quotes are in a separate table with its information, it feels more like a single table that has say CustomerId, Name, Address, QuoteId, QuoteDetails, TotalCost, etc. Everything that we've been told is evil and wrong in the RDBMS world (Normal Form and all that). So that alone is hard to get my head around since I've had it drilled into me for so long that it's bad to have data like that, but in the Document Database world it's the way things are done. It's a pretty big disconnect.
Isn't there performance issues with that? I mean, the idea is that you break up your "documents" in the RavenDb parlance along your aggregate lines, right? so if Customer is an aggregate it's OK to have Quotes be part of the Customer document (as a Quote is never without a customer), so it's not like you always have these huge object graphs for your entire data model?
Wayne, That is mostly because in RDBMS you are limited to a single value per column, and a limited number of columns. With document databases, that isn't the case, and you are free to store much more complex information inside the object.
The guiding principal is the transaction boundaries. Everything inside a document should have a single reason to change. Thing about aggregate in DDD, that is perfect match.
Not only isn't this a perf problem, you would usually gain perf, because you don't have to spread yourself all over the DB, joining stuff and making multiple queries.
In the Customer -> Quotes example, those would probably be separate things. A Quote can change independently of a Customer, so they don't belong on the same doc. But Order/OrderLines is a perfect example of why you want t a single doc, they are a transactional boundary, and an order line can't change without modifying the order. So they should be a single doc, and it simplify a WHOLE lot.
Off topic - why doesn't your "social login" support facebook? I think they don't use openid - they have their own "connect" thingy, but implementations exist that bundle connect & openid.
Ayende, i don't know if it has been already asked, if that's the case sorry.
My question is: can you please elaborate more on the differences about the design and usage of "relations" like concepts ("joins") inside a document db, specifically, ravendb?
I mean, if we split some data on more than 1 doc, but we have to "join" them, what are the possibilities? Creating an index, map/reduce style? Yes? No? What other options we have? That (along with how to model documents instead of tables/rows) i think is the more important aspect to clarify for people who would like to embrace doc dbs coming from a rdbms world.
One final note: how does "joining" in a doc db world (specifically, ravendb) performs in contrast with real joins in the rdbms world? I mean, we know we should avoid them but if we need to do them, what is the related weight increase? Imagine to make a parallel between a case of "SELECT vs SELECT+JOIN" in the rdbms world and a case of "SELECT vs SELECT+MAP/REDUCE/WHATEVER-IT-IS" in ravendb.
Thanks.
njy, I spoke extensively about those topics in the past. And it is getting repetitive to talk about generalities. Why don't you come up with an example model, and a list of questions/ tasks to do on this model. That would be much easier for me to handle.
In the Customers & Quotes example, how would you then be able to find Quotes from a single customer, if we don't deal with releations?
I know you've talked about that in the past, but one post here about a specific case, another one there about one solution... so...
ok, let me put it this way: for the good of doc dbs spreading in general, and in particular for the good of RavenDB, can you please make a general overview from A to Z of the "relations/joins in the doc dbs world" argument - with examples - here on the blog or (probably more usefull for you) on the ravendb's site? That could serve as a reference for possible adopters and in general people who whill be evaluating the thing, and that we can use a-la "go there and read" instead of "try searching ayende's blog... yeah, that blog with an average of 3 posts per day!" :-)
I think it can be very usefull for RavenDB.
Thanks.
Ayende, it would interesting series of posts that reviewed the cases where RavenDB could be used for order entry and purchasing. Some of the misgivings that people have regarding NoSQL are related to the idea that document database solutions are not good for transactional processing.
This could drive acceptance further for document db solutions, as it demonstrates that NoSQL is not merely an edge case, boutique solution.
I think part of the disconnect with NoSQL modelling stems from the fact that relational data allows you to start development with designing what data you need, and from there it becomes a matter of linking all the data together. I think (for better or for worse) this is the general way that devs begin building applications.
NoSQL on the other hand pretty much forces you to focus not on what data you need but instead how users will actually interact with your application, and take all of those user stories into consideration before you can even begin to think about how your database model will be.
Relational databases allow for both approaches, nosql really forces the latter.
Another thing that ties many developers to SQL databases are the necessity (actual or perceived) of being able to utilize existing reporting frameworks like SSRS. Do such reporting tools exist for any NoSQL databases?
Ayende, you experimented with some graphdb functionality in Raven a while back. Any plans to revive that?
If I need to suggest a disadvantage it would be the lack of supporting maintenance tools. None of the platforms have proper integrated tooling.
In SQL Server we have maintenance plans for example, integrated, automatically, and the entire proces can be managed by your average system administrator.
With the current NoSQL solutions this is a little more difficult and you quickly have to refer to bandaid solutions, scripts, etc.
@Micha: +1 for maintenance tooling (well, tooling in general), i was just about to say that too! I think we need to came out with some "main concepts" (3 to 6 seems reasonable enough) that are kind of fixed in stone and take for granted in the RDBMS world, and have them approached with the relative alternatives in the NOSQL world.
As of now we have:
differences in modeling data;
in absence of relations, what are the aternatives to old school "joins" and stuff?
tooling in general for developers, think query analyzer, designers, etc (main target: dev);
maintenance tools, backup, etc (main target: dba);
profiling
etc...
What else? What do you guys think?
Document databases are great for specific cases - and by 'cases' I dont just mean particular models, I also mean development scenarios - which may differ from 'everything is spec'd upfront' to 'the customer doesnt even really know what he wants'.
Then... throw REPORTING (I know, I know.. but it's important and obviously a question that needs a better answer before doc DBs will really take hold in corporate environments) in to the mix - if you tell the dev team "well, you have to send all your data that you want to report on, to an RDBMS", they will just ditch the NoSQL and use SQL.
Adam, maybe using transactional SQL database for reporting seems like a good idea but you're going to regret that very soon. To do any non-trivial reports you'll need a dedicated reporting database, no matter if you use SQL for your application or not, so you'll be better off separating transactional and reporting databases at the beginning.
@Micha @njy If a team decides that a document DB fits their scenario and they've invested time into learning how to model and program against a document DB, it would make sense to invest in learning the management side too. When have you ever met a (happy) programmer who would let a DBA restrict their technology choices?
To address the query analyzer/designer tools? Why do you need them? A document in Raven is a normal class. You would "design" it how you write any other POCO. Also, when you query a document DB, you retrieve a document. There are no joins to analyze. 95% of the time I'm using a SQL query profiler to find the slow joins in code. I don't have to do that with Raven.
For backups, read the docs. It's really simple. http://ravendb.net/docs/server/administration/backup-restore
@njy Ayende has a search box at the top right corner.
http://ayende.com/blog/search?q=document+modeling
Here is the "wrong" way to do NoSql joins: http://ayende.com/blog/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases
Here is the "right" way: http://ayende.com/blog/4466/that-no-sql-thing-modeling-documents-in-a-document-database
@Ryan " There are no joins to analyze. 95% of the time I'm using a SQL query profiler to find the slow joins in code. I don't have to do that with Raven."
In return, you still could have too many requests with any NoSQL solution, map/index performing badly and then you still have to digg into code, trial & error or use profilers. In the mailing list of ravendb these types of topics regularly come across, and quite often there are different approaches which perform much better.
I think a fair amount of time you save with a relational db system is spent into writing indexes/map/reduce and/or writing extra code (patch) to update and synchronize all the denormalized changes into other documents, code you normaly wouldn't write when using a relational system.
It wouldn't suprise me if the time being spent on implementing either relational or nosql would balance each other out. :)
@Ryan: maybe i didn't make myself clear.
First thing: i've not said that those topics were all uncovered as of today, on the contrary: some of them have been covered, but there is not a single page/place to look at, and since RavenDB is a product, i suggested it would be good for it (and, as a reflex, maybe for the whole nosql movement too).
Second: sometimes devs aren't dictators, sometimes there's a dialogue between devs and dbas, because their experience actually does matters, too (imho). So, if you should have a discussion, their topics and fears should be covered too, stuff that (maybe) devs normally don't take into account, like backup policies or maintenance plans. On top of that a nosql-like solution may be the only possible choice (think facebook, just as a silly example) but some other times either an rdbms or a nosql solution would see fit, but going through the nosql way with some "holes" along your path may hurt, so better talk in advance and be prepared. We're just discussing here, i think that's useful.
Other stuff: "it's just POCO" yeah, i got it, but you may want to work on the data to "play around" or "test different data designs" and you may don't want to be forced to create a test console app to do that. You may want to prototype stuff or see how a model will work in a doc db, trying to than query it to see results, or I may want to trow some queries and see how the system works, that is a use for a queryanalyzer-like tool. Anyway the answer for that is that there's a query tool inside the webadmin for RavenDB, so that's ok.
Regarding "no joins": you shuld tell Oren, because he talked about that (see this http://ayende.com/blog/4661/ravendb-live-projections-or-how-to-do-joins-in-a-non-relational-database ).
For backup: yeah, i read that part. I repeat: i was trying to make a list of possibile arugments to clear up for people coming from the RDBMS world wondering if everything will be doable and fine in this new NOSQL world. Maybe all in one page/place, and not scattered through 20 posts in multiple blog.
You guys see this as useful? Good! No? That's fine, we'll survive :)
@Ryan: "Ayende has a search box at the top right corner"
Thanks! Wow! Now i can add "able to use search box in Ayende's site" on my resumé :-) !
Ok, jokes apart: it is clear to you that i'm not asking here for a specific answer to a specific question? Instead i'm proposing to group together some specific "general" issues that people coming from rdbms land may have, the main doubts that they may have, and put them in a single place. And i'm asking here because Oren talks about this stuff, one time here, one time there, and it may be useful to group them together. Oh, and because Oren has a company, which in turn makes a product called RavenDB, which in turn may benefit from this kind of operation.
Cheers.
It is clear that this comment will be a positive one, because I'm using RavenDB a _lot_. Not just for 'playing around' but for software projects that hopefully make me (and my collegues) smile at the end of the month.
Now, let's google for "ravendb awesome". This will get you a ton of blogs an tweets that go like "wow, it is so awesome...". I'm sorry, I am not a native english speaker and don't know the correct definition of awesomeness, but I absolutely don't care if something is _awesome_. I am using raven because working with it is faster, cleaner and produces less troubles compared to when using SQL Server. In the end, it saves budget and I run into less headaches. This is why I use raven.
Sure, the relational/document-oriented mindshift hits you hard. Really hard. Even though RavenDB tries to hide a lot of the complexity from beginners and rewards your first efforts with some 'it just works' moments, you still have to go a steep learning curve if you want to use it in more complex scenarios.
RavenDB is not for everyone. I know that because I regularly need to explain what an ORM is and why not to write plain SQL in code (VB of course). I mean, these guys have 'software engineer' on their business card. No, Raven is not for them. For the rest of us (those reading blogs like this one) I think it is definitely worth the effort to learn about document modeling and how drastically it can simplify your daily business.
@Daniel Lang: thanks for your sharing.
Since you seem to have enough experience on the field I have a curiosity, if i may ask: are there any "fine tuning" phases (like creating some indexes in an rdbms) using ravendb, or you just (well... "just"...) need to work on the indexex definition, tuning the map/reduce part? Thanks.
@njy: Yes - there are many such things you wouldn't otherwise deal with when using a traditional sql solution. If you're interested, take a look here: http://daniellang.net/tag/ravendb/
This is what I consider to be the result of a really hard and steep learning curve. And there are pain points. For me, the hardest are migrations, lack of proper tool to inspect indexes, and ad-hoc querying. The last one can make you feel really sick, because there isn't even a good workaround except replicating an index out to sql-server, which I don't consider to be a workaround.
I personally don't like to feel sick. So what do we do if we run across a situation where we have the need for massive ad-hoc querying (e.g. reporting)? The answer is - I use SQL Server then.
The whole point of this NoSQL movement is to choose the right tools for the rights answers. At the moment, we're build a time-tracking system. This is something I wouldn't do in RavenDB. NHibernate is a perfect match here. I just find that RavenDB is the right tool for most of our application, but definitely not for all.
@Daniel Lang: thanks, your blog seems very interesting, and filled up with real world use cases. Definitely count me in as a new feed subscriber ;-)
Philip, session.Query<Quote>() .Where(q=>q.CustomerId == "customers/1234") .ToList();
Njy, I believe we have made it clear on the RavenDB site. Take a look here: http://ravendb.net/documentation/docs-document-design
Njy, Also, the average over the last year or so have been 1 blog post per day, more or less
David, While I agree it would be interesting, I would like to get real world scenarios from other people, rather than have to make up stuff. That also make it more interesting because I don't tailor the scenario to RavenDB capabilities.
Matthew, I would strongly disagree with that statement. In practically any application that I have seen, starting from the data model and then building the app was a mistake. It cements decisions that are made without actual understanding of the business scenarios and the needs of the application.
Dan, You can do reporting on top of a non relational database, yes. But for the most part, you want a dedicate reporting database, what that is (SQL or not) is an implementation decision that should be answered based on the data size, update frequency and the types of reports needed.
Vidar, Not really, no. Graph queries for RavenDB were added in a branch, but I decided that this is something that we want the community to do, not to do it ourselves. We want to focus on making RavenDB the best document database, not something that can do all things, but non too well.
Micha, a) Most NoSQL solutions require very little maintenance. With RavenDB, the most common regular maintenance is running backups. You can schedule that easily enough with external tools. No need for RavenDB to implement a scheduled backup process when it is already exists. b) Most NoSQL solutions assume multiple nodes running at the same time. Usually a lot of them. You go ahead and try to run some task on all nodes manually. You want to do that in a script. c) RavenDB comes with an awesome management tool
@Oren: thanks for the doc link, since it is in the old site i wasn't able find that. About the average posting stat: yeah that was just a number to give an idea, plus i was remembering when people insinuated in real life you were a robot because of the high frequency of posts... so i may have exaggerated a bit :)
Micha, RavenDB contains explicit code to avoid the too many requests issue. Badly performing indexes are actually quite rare. In 2.5 years I have seen exactly one case where the way that the index was defined was actually causing a performance problem, and that was a highly degenerate case. We usually recommend things on the basis of performance, but it is a ms difference during indexing more than anything else.
You can look at the public apps we have for RavenDB (this blog being the major one), there are a few indexes that we defined by hand, the rest are auto indexes defined by RavenDB. For the most part, the indexes defined by hand are for specific purposes, and are quite easy to work with. Certainly more easy than the common "how do I make this page efficient" that I see pretty much everywhere with relational databases.
@ayende, sorry I wasn't trying to say that starting from a data model is good, my point was that nosql databases punish you for that much faster for it.
I would say that a lot if devs design apps data first (I'd also say most are inexperienced creating large enterprise level apps it just bad), and because of that they hit the wall quicker that tells them they are doing things badly.
Matthew, I don't think that NoSQL punishes you for bad data models faster. Well, maybe, for the general case. With RavenDB, you have enough freedom to do a LOT of querying options. Some things might not be optimal, and often we recommend different ways of modeling, but you can make those queires.
Ayende, as a learning method for newbies, do you think modelling the documents after screen mockups (imagine they are well-defined transactions) is a good way to go?
@peter,
a pull request will be great.
https://github.com/fitzchak/RaccoonBlog
Alex, Designing things based on the actual interaction? (And usually the UI follows those interactions.) Yes, that would be a way of starting out, and you can modify things along the way when you discover new stuff.
I looked at RavenDB and would have liked to start a few projects working with it, but as with many developers like myself it would be on a commercial project not just in my 'spare time'. But unfortunately the pricing is just too high to justify 'experimenting' with this new technology.
To me the pricing model is alienating a huge amount of potential early adopters of technology and is a short sighted approach to getting what seems to be a great product the sort of user base that would bring it to the fore.
Simon, It costs 25$ a month. What do you expect? How much lower do you think it can be?
I am sorry, but even right now, I think that ravendb is priced far lower than it is worth. This is intentional, because we want to get as many users as possible.
I know lots of developers, many feeling the squeeze right now and looking to cut costs not increase them and the cost is still per instance, per month (which adds up).
Convincing people to move from a deeply entrenched tech is going to be hard enough as it it is, and the existing use of relational databases still works very well, it isn't actually broken.
I can see the benefits nosql would bring (and RavenDB seems good to go for commercial work) but the combination of cost and learning curve to experiment is going to put many off.
You may not agree, but I am one of those people, I read open-source and thought "right lets give this a go on my next project", then saw I have to sign up to a monthly plan and that combined with the effort to change tech was enough to put me off.
If you want to truly get the masses on board, in my opinion, get the user base first, monetize it later.
@DanielLang
out of curiousity, what were the factors which made you decide that a document database was not suitable for a time tracking application?
Simon, Compare the pricing for just about anything else, and you'll find that we are extremely competitive.
You might also want to check the pricing discussion in the mailing list here: http://groups.google.com/group/ravendb/browse_thread/thread/7aa34f35e49d01ab
And it is very easy to say "monetize it later" when you aren't the one actually paying for the development and work on the product.
Ayende, I appreciate you taking time to comment and take your points on board, I can see from the mailing list you have covered it all quite extensively.
I was just sharing my own personal opinion and if I am one of the target market I presume this should count. We do get away with SQL Express or MySQL a lot of the time, which costs nothing. I know the cost here is relatively small but as I said many are looking to reduce and not add monthly overheads.
Still it seems a very nice product and I have received only positive responses so far, so I was maybe a bit hasty to disregard it as an option.
I feel compelled to nitpick. In the 80s, the typical application had hundreds or possibly thousands of users. And it ran on an IBM mainframe, or something that looked like one. And it was phenomenally efficient in the use of (as you pointed out) scarce and very expensive resources.
"2 songs or 3 pictures"? That's an absurd frame of reference considering the only reason we have media files this large nowadays is because we have the cheap storage to keep them. No one would have thought to store a 3 megabyte image file on a hard disk back then. The way you word it makes it seem like that's legitimately what people were using them for. How about how many text files it could hold. Probably quite a few.
You actually made good arguments for an entirely different type of database: Object-oriented databases. I regularly see people wanting a database to just reliably store and retrieve data in their program, which takes the form of primitive types and objects. The ORM schemes are horrible. That they take a 5in thick book to teach is telling.
A top-notch OODBMS like AllegroCache makes things so easy, conceptually & practically. (I named them b/c they were the best last time I looked into these things.) AllegroCache had the benefit of coming with the Allegro CL platform, which is incredibly powerful/flexible. I could see the same ease of use in a mainstream language with some tools that auto-generate boilerplate to operate with OODBMS. Your thoughts?
I'll be resurveying those OODBMS's and taking a look at your RavenDB tonight.
Comment preview