I wish I could add an extra "like" every time I agree with what he is saying or he blows my mind with how he puts all the concepts I learned separately into one global picture.
I don't know if I am young or new in the subject, but that's what I call "perfect teaching". This guy is amazing! For many years I was disappointed from my professors and their (in)ability to teach contagiously. This man justifies my (so called) nagging.
+Giorgos Argyriou You have to keep in mind, that he is not only teaching, but also promoting. As in, he sort of glosses over the fact that the vast vast majority of your real projects will never ever need NoSQL as your primary data storage, and using NoSQL database where you really need something relational is a far more expensive mistake, than the other way around.
***** Yeah, he promotes NoSQL in general, not as a replacement - but that's what people inevitably take out of such well constructed presentations. The fact is, most developers already use relational DBs for everything and to insert NoSQL in your workflow you have to replace SQL in some way. Now, if you are using filesystem or in-memory hash table as your storage engine - then yeah, NoSQL could extend your horizons with very little performance hit. Otherwise you are incurring these massive penalties on architecture or feature set or extendability or stability of your applications in the name of mythical features or performance levels that you don't actually need. He doesn't spend much time explaining, which NEW problems are now solvable, and which of the old ones are definitely NOT - he spends most of the time straight out praising NoSQL.
***** See, you're doing it even worse. People think "fast and scalable? well duh, I need fast and scalable everywhere!" Except you don't mention, that "fast" could mean "slower than MySQL or Postres on real workloads", and "scalable" could mean "scalable far beyond what you'll ever need or use", and you also don't mention "forcing simple data structures", "rigidity of data representation", "inability to make deep changes", "inability to use any sort of advanced cross-cutting analytics", "unpredictable performance on very similar tasks from business perspective", etc. So no, if the purpose is truly to have a fast and scalable database, then you have to return to planning stage and completely change your decision process to better reflect actual needs of your application and not some generic marketing-talk.
Its just mindboggling to imagine about the level of clarity Martin speaks with. There are some people who attract you with their oratary skills and I pledge this guy is one such kind
Martin is the most lucid speaker on pretty much any complex topic in computing. I love this 50 minute talk. A great intro into the NoSQL movement. I did think that the explanation as to why NoSQL may succeed where OODBS failed was no so convincing and would have loved to hear more on this particular topic. Highly recommended!
Martin your talk made me understand a hell a lot about NoSQL Which can't even gained after 2 years of practical experience. If someone had kind of presentation for SQL it might have been used better in the industry. It's best!!
I was just thrown into NoSQL for a project a week ago and found this very interesting, as well as entertaining. It's really hard to get rid of all these ORM-related paradigms first, but I love the relief that comes with simplicity.
Great introductory talk. The best part of it was that he didn't take a giant steaming dump on relational models which a) still pay most of our bills in direct or indirect ways, and b) still absolutely have a place in the world of data. I think his premise of 'polyglot persistence' is absolutely where things are headed. I've already seen some pretty neat implementations using RDBMS as the final authoritative backing store, but having clustered MongoDB instances as mostly-fresh satellite caches.
This was a fantastic presentation! I am fairly ignorant to all of these concepts, and I am walking away with a better understanding of each. Thank you!
Martin Fowler has done more to help me be a better coder than anyone else alive. His book on refactoring is the single most useful practical programming text I've ever read. Thank you sir!
I found this to be one of the best presentations I’ve ever seen. It was very clearly explained. I wish he would do a follow up now 6 years later and revisit this space and how has it changed or is it still pretty much back where it was in 2012, As a complete Noob I’m wondering what has changed in the past six years.
Great intro. To sum up, NoSql is being used because of the big data and impedance problem of relational database. There are 4 categories: Key-value, document store, column family and graph. The first 3 are aggregate-oriented and all 4 are schemaless; NoSql are good for using one kind of aggregate constantly and it needs to handle trade off between consistency and availability(or response time), which usually is a business decision. NoSql is not only good for big data, also for easier development.
Great breakdown of NoSQL. I appreciate the part of the talk where you show the graphic of using multiple data storage types to meet a systems needs using polyglot persistence. This video has made me think even deeper about the full systems interaction between the different data stores.
Great explanation of the different models of NoSQL databases. Martin Fowler does his usual breakdown of complicated subjects into informative presentations.
Fantastic talk, really interesting. Going through something similar now. I think one of the other things about aggregate databases is that because there's no explicit schema, documents can end up in unexpected states, unless you verify everything before an update via the implicit schema which is not very feasible. You basically can't tell how something went wrong in your documents at that point which is pretty worrying.
If it's a 'strategic' or 'tactical' project you STILL need to consider how the data will be used. You don't just select NOSQL for the sake of using something new. If you select nosql for a stategic project w/o understanding how the data will be used you better line up your next job fast.
Very clear presentation about the history of databases & comparing relational vs. NoSQL. It's entirely logical that one application should utilize separate database technologies to serve the various storage needs of the app, i.e., a relational database for transactional data (subject to diverse queries) & NoSQL for more linear aggregation (polyglot persistence). However, I think emerging from this will be individual solutions that, under the hood, utilize multiple persistence technologies.
Quite a lot of content out there trying to explain NoSQL. This video really knocks it out of the park. A must if you are new to NoSQL. Loved his quip on "who wants to be seen wearing XML in public".
The problem is once I listened to the amazon engineer talk where he advised to use sql till u reach 10 million users as Postgres sql and MySQL are very stable and one will find all the answers to the problems since it has been for a long time. Thus I wonder which will save time.
Good talk, and I agree that it's good to know multiple ways of storing data. He explains things well. However, I question the recommendation of using the immature and experimental technology for your mission critical systems: it's probably better the other way around.
Awesome video. I was working on a talk about how to introduce database technology into a second course in Computer Science for High School teachers and Martin's talk gave me some excellent ideas.
In surveying the NoSQL landscape, I see three broad classes of database: 1. The Object Databases, who weren't invited to the party because no one thinks they're cool anymore and it's clear they're not going to dethrone SQL. 2. The Graph Databases, who are very interesting and do things SQL isn't good at, but are...kind of bewildered that they've been inducted into this "movement" when they're just trying to find neat ways to calculate Six Degrees of Kevin Bacon. 3. The Aggregate Databases--a perceptive and illuminating category--which are really a reactionary group, in that they want to go back to a world before RDBMS and revive the hierarchical data models of the 1960s and 70s. They have all the problems of the old hierarchical systems (it becomes nightmarish the moment you want to look at the data from some different angle, child records that refer to the same thing in the real world can't be kept consistent with each other), plus the brand-new one of inconsistent formats, because schemas are an intolerable restraint on developers coding things however they want from day to day. There's probably a good use for every one of them--sometimes you just want a really good hash table!--but NoSQL came to prominence at a particular moment when RDBMS was struggling to cope with scale and distribution. And that looks to have been a moment, not a trend.
"I can only ever remember what it means on Tuesdays." Oh man that joke died so hard I was pissing myself laughing. Fantastic presentation BTW. This should be the first point for everyone to understand NoSQL.
I see his name pop up constantly as an authority figure on architecture, its quite amazing actually how well respected he is, seeing him talk for the first time I don't doubt that that respect is well placed.
46:30 "I've got some friends who work at *The Guardian* newspaper ... the article for them is a natural aggregate ... for them spreading that article accross relational databases is a *pain in the neck* ..." Later: "some NoSQL databases are *immature* , we don't have the tools, the experience, the knowledge to work with them well; we've got decades of experience with sql databases" Fast forward to 2018 (www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres). The Guardian: " *Bye bye Mongo, Hello Postgres* ... We decided to purchase OpsManager - Mongo’s database management software - along with a Mongo support contract - to help with the cloud migration ... Due to editorial requirements, we needed to run the database cluster and OpsManager on our own infrastructure in AWS rather than using Mongo’s managed database offering. This was non-trivial, as *Mongo didn’t provide any tooling* for getting set up easily on AWS - we needed to hand write the cloudformation to define all the infrastructure, and on top of that we wrote hundreds of lines of ruby scripts to handle installation of monitoring/automation agents and orchestration of new DB instances ... Since migrating to AWS we’ve had two *significant outages due to database problems* , each preventing publication on theguardian.com for at least an hour. In both occasions *neither OpsManager nor Mongo’s support agents were able to help us much* , and we ended up solving the problem ourselves ... Automatically generating database indexes on application startup is probably a bad idea ... OpsManager *didn’t really deliver on its promise* of hassle-free database management. For instance, actually managing OpsManager itself - in particular upgrading from OpsManager 1 to 2 - was *very time consuming* , and required specialist knowledge about our OpsManager setup. It also *didn’t deliver on its “one-click upgrade” promise* , due to changes in the authentication schema between different versions of Mongo DB. We lost at least two months of engineering time a year doing this database management work. All of these problems, combined with the *hefty annual fee* we were paying for the support contract and OpsManager, left us looking for an alternative database option ... Since all our other services are running in AWS, the obvious choice was DynamoDB - Amazon’s NoSQL database offering. Unfortunately at the time *Dynamo didn’t support encryption at rest* . After waiting around nine months for this feature to be added, we ended up giving up and looking for something else, ultimately choosing to use Postgres on AWS RDS. “ *But postgres isn’t a document store!* ” I hear you cry. Well, no, it isn’t, but it does have a *JSONB column type, with support for indexes on fields within the JSON blob* . We hoped that by using the JSONB type, we could migrate off Mongo onto Postgres with minimal changes to our data model. In addition, if we wanted to move to a more relational model in future we’d have that option. Another *great thing about Postgres is how mature it is* : every question we wanted to ask had in most cases already been answered on Stack Overflow. Lesson learned, the hard way.
Start relational, stay relational. People really do love wasting time and money. There are obvious use-cases for non-relational databases, but it is very doubtful that's where you should begin when building out a domain. As noted, Postgres supports JSONB columns. Best of both worlds.
Yep. We're still here, us relational folks, and our stuff...just works. The world is full of developers who just want to hack away, and hate the discipline relational databases impose on them. We'll still be here when all their stuff breaks again, like it always does.
pause video at 0:23, click the gear icon in bottom right of video. Select speed, then set the speed at 1.5. then play the video. this video is more entertaining to watch it like this
Thanks for this introduction to NoSQL Martin. Just FYI, this blog entry www.tincat-group.com/mewsings/2007/01/otlt-metadata-piece-not-apartheid.html shows a NoSQL graphic half-way down. It was written prior to the introduction of hash tags. It is conceivable that others came up with nosql independently after we did (Tom, Ashley and me) and had not seen our graphic prior to that point, but Tom has the domain names, so there is a thread of the NoSQL movement that arose just slightly earlier out of the NF2 (non-first normal form, pre-relational) world, recognizing we did not popularize it. We figured that we passed it into the UniVerse and it was picked up.
@50:00 indeed, Excel is engine of the business. I don't know how many times developer complained "we should ban the use of excel in this company, the excel spreadsheet is not requirements"
great talk, i like the way he aims the talk at all levels, and does it very very well. very much appreciated. I guess you have to be british to get the humour!
Martin Fowler is just amazing
I wish I could add an extra "like" every time I agree with what he is saying or he blows my mind with how he puts all the concepts I learned separately into one global picture.
Definitely this
I don't know if I am young or new in the subject, but that's what I call "perfect teaching". This guy is amazing!
For many years I was disappointed from my professors and their (in)ability to teach contagiously. This man justifies my (so called) nagging.
+Giorgos Argyriou He's very impressive.
+Giorgos Argyriou You have to keep in mind, that he is not only teaching, but also promoting. As in, he sort of glosses over the fact that the vast vast majority of your real projects will never ever need NoSQL as your primary data storage, and using NoSQL database where you really need something relational is a far more expensive mistake, than the other way around.
***** Yeah, he promotes NoSQL in general, not as a replacement - but that's what people inevitably take out of such well constructed presentations. The fact is, most developers already use relational DBs for everything and to insert NoSQL in your workflow you have to replace SQL in some way.
Now, if you are using filesystem or in-memory hash table as your storage engine - then yeah, NoSQL could extend your horizons with very little performance hit. Otherwise you are incurring these massive penalties on architecture or feature set or extendability or stability of your applications in the name of mythical features or performance levels that you don't actually need.
He doesn't spend much time explaining, which NEW problems are now solvable, and which of the old ones are definitely NOT - he spends most of the time straight out praising NoSQL.
***** See, you're doing it even worse.
People think "fast and scalable? well duh, I need fast and scalable everywhere!" Except you don't mention, that "fast" could mean "slower than MySQL or Postres on real workloads", and "scalable" could mean "scalable far beyond what you'll ever need or use", and you also don't mention "forcing simple data structures", "rigidity of data representation", "inability to make deep changes", "inability to use any sort of advanced cross-cutting analytics", "unpredictable performance on very similar tasks from business perspective", etc.
So no, if the purpose is truly to have a fast and scalable database, then you have to return to planning stage and completely change your decision process to better reflect actual needs of your application and not some generic marketing-talk.
***** So... why then reply at all if your answer is misleading and incomplete, and people shouldn't take it into consideration?
Its just mindboggling to imagine about the level of clarity Martin speaks with. There are some people who attract you with their oratary skills and I pledge this guy is one such kind
This video gave me more than 2 days reading articles and watching other vids non-stop
Its 10days and still reading, he is amazing put all of the high level stuff in a clear manner now I can read all of them individually
21:40 most important part of the presentation. How to make a choice between relational and nosql...
44:40 has further details
Precisely. I feel like this is the most decisive quality.
Amazing that 11 years later his talk is still massively helpful and a great intro to NoSQL DBs
The best NoSQL talk I've come across.
40:40 the best explanation of CAP theorem I've ever heard (+ previous example of booking a hotel room at 37:52)
Just great! What a gift to be so fluid and yet so comprehensive.
Excellent presentation. Simple, plain English and examples to help understand the basics of NoSQL concept. Thank you Martin! Kevin
Martin Fowler is very good at "distilling" complex stuff into easy to understand concepts. Excellent talk!
Martin is the most lucid speaker on pretty much any complex topic in computing. I love this 50 minute talk. A great intro into the NoSQL movement. I did think that the explanation as to why NoSQL may succeed where OODBS failed was no so convincing and would have loved to hear more on this particular topic. Highly recommended!
It's been sometime since I started looking for what is NoSQL and what the fuzz all about. I think this video is simply my answer.
10 years later and this was very accurate.
Glad that I found this video. Explains almost everything you need to know about NoSQL. Speech is absolutely perfect.
if only everyone teaches like this...
One of the best intro about NoSQL Dbs and especially the CAP theorem
Martin your talk made me understand a hell a lot about NoSQL Which can't even gained after 2 years of practical experience. If someone had kind of presentation for SQL it might have been used better in the industry. It's best!!
I was just thrown into NoSQL for a project a week ago and found this very interesting, as well as entertaining.
It's really hard to get rid of all these ORM-related paradigms first, but I love the relief that comes with simplicity.
Great introductory talk. The best part of it was that he didn't take a giant steaming dump on relational models which a) still pay most of our bills in direct or indirect ways, and b) still absolutely have a place in the world of data. I think his premise of 'polyglot persistence' is absolutely where things are headed. I've already seen some pretty neat implementations using RDBMS as the final authoritative backing store, but having clustered MongoDB instances as mostly-fresh satellite caches.
This was a fantastic presentation! I am fairly ignorant to all of these concepts, and I am walking away with a better understanding of each. Thank you!
Brilliant presentation. Today is the 16th of December. His birthday is two days from now. Happy birthday, Martin Fowler.
He is THE BEST teacher I ever had!
That's much better explanation of CAP theorem than what you typically find online...
Martin Fowler has done more to help me be a better coder than anyone else alive. His book on refactoring is the single most useful practical programming text I've ever read. Thank you sir!
It's 2024 already but it feels like we're still don't know mush on how to actually use nosql properly.
correct
I found this to be one of the best presentations I’ve ever seen. It was very clearly explained. I wish he would do a follow up now 6 years later and revisit this space and how has it changed or is it still pretty much back where it was in 2012, As a complete Noob I’m wondering what has changed in the past six years.
Great intro. To sum up, NoSql is being used because of the big data and impedance problem of relational database. There are 4 categories: Key-value, document store, column family and graph. The first 3 are aggregate-oriented and all 4 are schemaless; NoSql are good for using one kind of aggregate constantly and it needs to handle trade off between consistency and availability(or response time), which usually is a business decision. NoSql is not only good for big data, also for easier development.
+Xiangyang Xiao Nice summary. thanks
This is great. I heard that UnitedHealth group is hiring a MarkLogic
NOSQL Development role, let me know if you want to hear more.
Great breakdown of NoSQL. I appreciate the part of the talk where you show the graphic of using multiple data storage types to meet a systems needs using polyglot persistence. This video has made me think even deeper about the full systems interaction between the different data stores.
Great explanation of the different models of NoSQL databases. Martin Fowler does his usual breakdown of complicated subjects into informative presentations.
Wholesome video, which covers every topic of NOSQL !!!
Fantastic talk, really interesting. Going through something similar now. I think one of the other things about aggregate databases is that because there's no explicit schema, documents can end up in unexpected states, unless you verify everything before an update via the implicit schema which is not very feasible. You basically can't tell how something went wrong in your documents at that point which is pretty worrying.
Splendid method of introducing to the concept of NoSQL. Must watch for anyone new to this domain. Thankyou Martin.
If it's a 'strategic' or 'tactical' project you STILL need to consider how the data will be used. You don't just select NOSQL for the sake of using something new.
If you select nosql for a stategic project w/o understanding how the data will be used you better line up your next job fast.
This dude is amazing! Will watch all his conferences!
Martin Fowler, is a great man. The conference is perfect !
Very clear presentation about the history of databases & comparing relational vs. NoSQL. It's entirely logical that one application should utilize separate database technologies to serve the various storage needs of the app, i.e., a relational database for transactional data (subject to diverse queries) & NoSQL for more linear aggregation (polyglot persistence). However, I think emerging from this will be individual solutions that, under the hood, utilize multiple persistence technologies.
It was really great listening to this. Clear cut concept for a beginner. Thanks a ton :) and a down thumb for the audience.
Fowler is one of the best OOPSLA speakers I've heard.
Great Vid. I often find myself losing focus during such tech talks, but that was not the case here! Props to Mr. Fowler !
Great talk on NoSQL by Martin Fowler. Incredibly articulate.
not only an excellent instructor but also super funny
Always feels good to listen from the Guru.
Quite a lot of content out there trying to explain NoSQL. This video really knocks it out of the park. A must if you are new to NoSQL. Loved his quip on "who wants to be seen wearing XML in public".
Great Talk. Highly recommended to spend an hour to learn some new stuff.
The problem is once I listened to the amazon engineer talk where he advised to use sql till u reach 10 million users as Postgres sql and MySQL are very stable and one will find all the answers to the problems since it has been for a long time. Thus I wonder which will save time.
Excellent introduction of NoSQL :)
What a great presentation.. He absolutely knows what he talks..
A great presentation over the different NoSql approaches. Thanks for sharing.
The king
Good talk, and I agree that it's good to know multiple ways of storing data. He explains things well. However, I question the recommendation of using the immature and experimental technology for your mission critical systems: it's probably better the other way around.
Awesome talk and good introduction to NoSQL storage solutions. Must watch for getting to know the basics of NoSQL
Very well thought out, and steady continuous stream of presentation. Thanks for sharing.
WoW ..great explanation about NOSQL and I realized the importance of NOSQL vs RDBMS
Awesome video. I was working on a talk about how to introduce database technology into a second course in Computer Science for High School teachers and Martin's talk gave me some excellent ideas.
Such a Brilliant talk. Got the hang of NoSql databases. Thanks so much.
In surveying the NoSQL landscape, I see three broad classes of database:
1. The Object Databases, who weren't invited to the party because no one thinks they're cool anymore and it's clear they're not going to dethrone SQL.
2. The Graph Databases, who are very interesting and do things SQL isn't good at, but are...kind of bewildered that they've been inducted into this "movement" when they're just trying to find neat ways to calculate Six Degrees of Kevin Bacon.
3. The Aggregate Databases--a perceptive and illuminating category--which are really a reactionary group, in that they want to go back to a world before RDBMS and revive the hierarchical data models of the 1960s and 70s. They have all the problems of the old hierarchical systems (it becomes nightmarish the moment you want to look at the data from some different angle, child records that refer to the same thing in the real world can't be kept consistent with each other), plus the brand-new one of inconsistent formats, because schemas are an intolerable restraint on developers coding things however they want from day to day.
There's probably a good use for every one of them--sometimes you just want a really good hash table!--but NoSQL came to prominence at a particular moment when RDBMS was struggling to cope with scale and distribution. And that looks to have been a moment, not a trend.
I learned lot out of it. Earlier concept from what all option available really good.Thanks Martin fowler
Best noSQL intro ever seen
Every developer must see this.
"I can only ever remember what it means on Tuesdays." Oh man that joke died so hard I was pissing myself laughing.
Fantastic presentation BTW. This should be the first point for everyone to understand NoSQL.
so what did you understod?
Very clear as usual with Martin Fowler
Nice presentation from past 👍🏻
Beautiful Presentation and excellent demonstration of skills and knowledges
Martin Fowler, thanks you are the best
I see his name pop up constantly as an authority figure on architecture, its quite amazing actually how well respected he is, seeing him talk for the first time I don't doubt that that respect is well placed.
The best ever session that I have seen!
Every modern developer should watch it
46:30 "I've got some friends who work at *The Guardian* newspaper ... the article for them is a natural aggregate ... for them spreading that article accross relational databases is a *pain in the neck* ..."
Later: "some NoSQL databases are *immature* , we don't have the tools, the experience, the knowledge to work with them well; we've got decades of experience with sql databases"
Fast forward to 2018 (www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres).
The Guardian: " *Bye bye Mongo, Hello Postgres* ... We decided to purchase OpsManager - Mongo’s database management software - along with a Mongo support contract - to help with the cloud migration ... Due to editorial requirements, we needed to run the database cluster and OpsManager on our own infrastructure in AWS rather than using Mongo’s managed database offering. This was non-trivial, as *Mongo didn’t provide any tooling* for getting set up easily on AWS - we needed to hand write the cloudformation to define all the infrastructure, and on top of that we wrote hundreds of lines of ruby scripts to handle installation of monitoring/automation agents and orchestration of new DB instances ... Since migrating to AWS we’ve had two *significant outages due to database problems* , each preventing publication on theguardian.com for at least an hour. In both occasions *neither OpsManager nor Mongo’s support agents were able to help us much* , and we ended up solving the problem ourselves ... Automatically generating database indexes on application startup is probably a bad idea ... OpsManager *didn’t really deliver on its promise* of hassle-free database management. For instance, actually managing OpsManager itself - in particular upgrading from OpsManager 1 to 2 - was *very time consuming* , and required specialist knowledge about our OpsManager setup. It also *didn’t deliver on its “one-click upgrade” promise* , due to changes in the authentication schema between different versions of Mongo DB. We lost at least two months of engineering time a year doing this database management work. All of these problems, combined with the *hefty annual fee* we were paying for the support contract and OpsManager, left us looking for an alternative database option ... Since all our other services are running in AWS, the obvious choice was DynamoDB - Amazon’s NoSQL database offering. Unfortunately at the time *Dynamo didn’t support encryption at rest* . After waiting around nine months for this feature to be added, we ended up giving up and looking for something else, ultimately choosing to use Postgres on AWS RDS.
“ *But postgres isn’t a document store!* ” I hear you cry. Well, no, it isn’t, but it does have a *JSONB column type, with support for indexes on fields within the JSON blob* . We hoped that by using the JSONB type, we could migrate off Mongo onto Postgres with minimal changes to our data model. In addition, if we wanted to move to a more relational model in future we’d have that option. Another *great thing about Postgres is how mature it is* : every question we wanted to ask had in most cases already been answered on Stack Overflow.
Lesson learned, the hard way.
Start relational, stay relational. People really do love wasting time and money. There are obvious use-cases for non-relational databases, but it is very doubtful that's where you should begin when building out a domain. As noted, Postgres supports JSONB columns. Best of both worlds.
Yep. We're still here, us relational folks, and our stuff...just works. The world is full of developers who just want to hack away, and hate the discipline relational databases impose on them. We'll still be here when all their stuff breaks again, like it always does.
Thank you Martin for your awesome talk.
Super delivery
Very nice and neatly laid out
Very well explained !! Cheers to Martin's energy ! :-)
Easy to understand and follow. Thank you! Mr.Fowler.
Excellent overview all around! Thanks, Martin Fowler. Also, love the way you strip false defenses and run religious wars out of town. :)
pause video at 0:23, click the gear icon in bottom right of video. Select speed, then set the speed at 1.5. then play the video. this video is more entertaining to watch it like this
Thanks for this introduction to NoSQL Martin. Just FYI, this blog entry www.tincat-group.com/mewsings/2007/01/otlt-metadata-piece-not-apartheid.html shows a NoSQL graphic half-way down. It was written prior to the introduction of hash tags. It is conceivable that others came up with nosql independently after we did (Tom, Ashley and me) and had not seen our graphic prior to that point, but Tom has the domain names, so there is a thread of the NoSQL movement that arose just slightly earlier out of the NF2 (non-first normal form, pre-relational) world, recognizing we did not popularize it. We figured that we passed it into the UniVerse and it was picked up.
Most important learning is at: 27:38
@50:00 indeed, Excel is engine of the business. I don't know how many times developer complained "we should ban the use of excel in this company, the excel spreadsheet is not requirements"
Excellent presentation. Like all his books, this presentation is also very clear,simple yet detailed. Thanks for sharing.
This talk is much more fun with subtitles on. Lovely :)
use different database to solve different problems
Best explanation! Thank you for such good content!
this talk is amazing thank you for sharing!
I am starting thinking if teaching is also a god gift. Wow, I was bored and now, I am curious and interested like a good movie is going on.
Thanks Martin for a nice orientation to NoSQL.
Although ,I disagree with some statements.
But, overall it is very good presentation, as always well-articulated.
Thank You Martin.
This is undoubtedly a master in his field but I struggle with listening to the tone of his voice. He sounds as if he was the wisest guy ever born.
I worship Martin fowler
The guy doesn't stutter, stumble or lose his place once. It's one continuous and steady stream of thought.
I love the /dev/null database. It's so fast and web-scale.
Very Nice Presentation on NoSQL, Thank You for Sharing.
Impressive presentation. Thanks, Martin.
informative!!
Great talk
Brilliant talk
Excellent lecture. Thank you for sharing.
great talk, i like the way he aims the talk at all levels, and does it very very well. very much appreciated. I guess you have to be british to get the humour!
Very nicely explained