Webinar recordingMigrating from a Relational Database to RavenDB
The recording of my webinar couple of weeks is available. I think it was a great session and would love your feedback.
More posts in "Webinar recording" series:
- (26 Aug 2022) Modeling Relationships and Hierarchies in a Document Database
- (26 Jul 2022) RavenDB & Messaging Transactions
- (24 May 2021) The Rewards of Escaping the Relational Mindset
- (15 Jan 2021) Filtered Replication in RavenDB
- (04 Dec 2020) RavenDB & Your Operations Team
- (28 Oct 2020) Advanced Search Scenarios in RavenDB
- (27 Aug 2020) The App that Guarantees You're Going Out This Saturday Night
- (10 Jul 2020) Multi tenancy with RavenDB
- (02 Jul 2020) Practical indexing with RavenDB
- (16 Jun 2020) Using RavenDB as a queuing infrastructure
- (09 Jun 2020) RavenDB Polymorphism at scale
- (25 May 2020) Event sourcing and RavenDB
- (07 Apr 2020) Managing Data in Distributed Environment
- (06 Apr 2020) Building a grown up database
- (12 Mar 2020) Migrating from a Relational Database to RavenDB
Comments
Great Video... one observation is Oren's audio is 'muddy'. The introduction voice was perfectly clear, but Oren's narrative was difficult to understand. I notice this in every Oren video I've listened to recently, and I suspect it is partially due to the quality of Oren's voice, but a head boom mic might help and some work on the equalizer.
Brent,
Thanks, this was the first time that we had a webinar in this setup, we'll try to do better next time.
Interesting video. Oren. One thing I have to note - if the code from first solution is written that way, that shows that an author didn't know and/or care how often he actually queries the db. If that is the case - it's likely the person won't care in case of document database (or likely any other type) as well. It's a mindset you have to adopt - thinking about what happens underneath and optimizing accordingly. I realise that's an example solution, but unfortunately, I have seen same thing several times on multiple projects. Developer with "its-ORM-it-will-figure-it-out" mentality calls SaveChanges in a loop instead of doing some simple batching.
Gleb,
The sample app is literally the sample application for best practices .NET application, see: https://github.com/dotnet-architecture/eShopOnWeb
There is a chapter on working with data: https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/work-with-data-in-asp-net-core-apps
I can assure you that the people who wrote it are at least very familiar with the technologies in question. They may not have paid much attention, having other things to look at, but the state of this application isn't anything unique.I have seen such things in production applications written by experts who cared about performance. The "pit of success" is a thing, and relational databases / ORM tend to push you away from that into a very different pit.
Comment preview