For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Jason -
Nisarg Shah -
Matt Lewandowski -
BDGWin -
Top comments (18)
Nested data structures are a pain to load and save to the database. That’s the primary reason ORMs exist. They auto generate code objects based on the tables or vice versa and handle saving nested objects in one transaction. I hate ORMs but I am a fan of “micro ORMs” like Dapper, which just maps rows to objects.
Instead of using an ORM for nested objects, I store the object as a JSON document. Postgres has a lot of good functionality around these.
I'm the database. I have data organized into related tables: there is a
stablestable with addresses, capacity, and so forth; ahorsestable containing names and vitals and a link to thestablequartering the horse; ariderstable containing other names and other vitals; and ahorse_riderstable linking individual riders to individual horses, since a rider may switch out or share horses. There's also astatisticstable with event names, times, and awards for a given horse; each record is a separate event.You're an application which displays horse data and allows users to edit and create more horse data. You need to talk to me in order to make that happen.
There are a few ways of accomplishing this. Object-relational mapping is one of the more common approaches but is by no means unambiguously the best (it's been called "the Vietnam [War] of computer science") and I tend to agree with that characterization).
With an object-relational mapper, you think about how you want to work with horse data and create a set of models which loosely correspond to my schema. You might combine the
horsesandstatisticstables into yourHorsemodel, for example, and will likely not even consider thehorse_ridersjunction table at all -- the O/RM abstracts that part away for you. YourStableobject even has its own collection ofHorses attached, which can be eagerly or lazily loaded with little to no effort on your part! This loose correspondence is what we call the object-relational impedance mismatch: aHorsewith its own statistics may be easier to work with in the application context, but it's different from how the data are actually represented. This saves time in the short term but makes adaptation much more difficult. When (it is not a question of "if") you need to do something you didn't originally account for, you will wind up doing one of two things:This is not to say that object-relational mapping is without advantages. It makes the first 90% of data access pretty straightforward, especially if you're using an object-oriented language. And it tends to use lowest-common-denominator functionality of the database, if supporting multiple engines is a pressing concern. But I don't feel that those advantages outweigh the inevitable drawbacks, especially when there are alternatives like the data mapper pattern.
That helps! Thanks!
You want to talk to someone.
You don't speak their language.
You ask someone to translate for you.
Something gets translated wrong.
You are now angry.
(SCNR)
how do you know that the translated got wrong without knowing the other language?
You asked for a goat in your language and you got a dog back.
Funny! Thanks!
Imagine you have a box that automatically order all your building blocks in whatever way you want to.
Your building blocks are data entries in the database.
The magic box is the ORM which allow you to make a better use of your building blocks.
Let's say you are creating a boat, so you need round pieces for the life boats. You ask to box for only round pieces.
In development this is called a query and a ORM help you to query in the DB
Let's assume you buy more building blocks. You put them in the magic box and everything is order.
An ORM will help you to add data to the database taking care of inner capabilities of the DB. By examples if the tables exist or not. If the magic box knows the type of building block or it is the first time it see it.
Now imagine you used to buy Legos, and found a compatible alternative brand, so you buy thoose and put them in your magic box.
An ORM also take cares of creating databases.
Now imagine your father or mother bought a bunch of building blocks as a surprise gift for your birthday, the box will take care of not letting you know those are there untill your parents decide to allow it. An ORM handle users and permissions in an easy way.
I love this building blocks analogy! I also agree that it seems like many of these folks haven't met a 5-year-old. Extending the blocks analogy...
Imagine that I ask you to make some sculptures of fishes for me. I don't really care what material you use to make the sculpture - you can use clay, or legos, or popsicle sticks. As long as it's a sculpture, and the things you give me look like fishes, I'm happy.
The fish is the object, the database is the material (clay/legos or maybe MySQL/PostgreSQL), and you, the sculptor, are the object-relational mapper. Maybe you started making fishes out of legos, but now you like making them out of clay, but I'm still happy because you keep giving me fishes.
Your fishes are a great way metaphore for models!
Very nice analogy!Thanks!
Thanks, I'm surprise this 5 year old frame, is not respected as the title indicates.
I have add another comparison, if remember anything else I'll keep them coming.
Gents during the 90's where complaining about how error prone was retrieving data from relational databases for use with applications, so some other gents came up with a way of (M)apping the (R)elational models of rdbms to (O)bjects in their applications (by referring to db rows as objects and table columns as attributes) as means of addressing said issues thus giving birth to the ORM approach to application data management.
From the early days of computing, databases and programming languages went in somewhat different directions as to how they represent and interact with data. Databases ("R"elational stuff) mainly emphasized fast access to large volumes of information on disk, while languages that emphasize manipulation of "o"bjects in a computer's memory had different needs than databases. Thus, databases and traditional programming languages evolved separately, serving different audiences with somewhat different needs.
However, many/most "traditional" applications require database access in some form or another. And so, databases and applications have been joined at the hip more or less as long as they've existed, even though at a low level they remain architected very differently.
The problem is that this disconnect between runtime objects and relational data led to coding difficulties of various kinds. It was just never super reliable or simple for applications to interact with databases. SQL, the most common language for data access and interaction is very different in syntax and execution from other "ordinary" programming languages like C. For one thing, a C compiler for example can't interpret SQL. For this reason, SQL commands have to be run by an application "on faith" so to speak. A compiler can't check a SQL command for errors before it runs, and it doesn't have a way to describe an expectation of results from a database query.
What ORM tries to do is unify relational data and runtime objects so that the complexities, nuances, and hazards of database access are hidden -- and made to look like any other runtime object. When it works, code is easier to write and maintain. It goes haywire when ORM introduces nuances or unexpected behavior of its own. For this reason, based on a range of developer experiences and further wide range of ORM libraries out there, it remains a somewhat polarizing subject in the dev community.
Not sure this explains it "like you're five," but.... this is my best shot. :-)
It is not for a 5 year old, but it is a nice explanation. I appreciate that you took the time. :-)
You are in a Chinese restaurant and you don't speak Chinese. You were given the menu with Chinese texts that you don't understand. In order for you to to order, you need to study Chinese and tell the waiter what you want by speaking in Chinese. That's fine if you are not hungry enough and you have time to study the language before you can eat.
Now every customer who doesn't understand the language have to study it before they can eat. The line outside the restaurant became very long. And that's not good for the business. So the owner decided to create a new menu where he matched every menu item with a picture and a number so that when you order from the waiter, you either just point to the picture or tell the number. That makes it easier for you tell what you want to eat.
I am a translator that will talk to any database you could want.
So glad you asked this Q!