Hey! I am aware of:
https://en.wikipedia.org/wiki/Object–relational_impedance_mismatch
And the fact that JPA is supposed to solve this, isn't however MongoDB way more convenient in the case of Object Oriented Languages?
Hope to hear some opinions.
1 messages · Page 1 of 1 (latest)
Hey! I am aware of:
https://en.wikipedia.org/wiki/Object–relational_impedance_mismatch
And the fact that JPA is supposed to solve this, isn't however MongoDB way more convenient in the case of Object Oriented Languages?
Hope to hear some opinions.
<@&987246584574140416> please have a look, thanks.
While you are waiting for getting help, here are some tips to improve your experience:
If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.
Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.
they all have their advantages and disadvantages
we are using mongo at my job and sometimes i miss my relational db as well
being schemaless can be a huge pain sometimes
backwards compatibility in case u have to rollback a buggy deployment is also a big problem
Mongo isn't purely schemaless. Transactions and sharing in mongo are also immature.
What data requirements do you have? Impedance mismatches are rarely the bugbear neward made it out to be, and he damn well knows it.
Sharding, not sharing.
Jpa does not solve the mismatch. It perpetuates it.
wym @hybrid cargo ?
My understanding is that a mismatch happens because a relational database may represent a single entity while an object in your OOP language may represent a complex aggregation of multiple entities, which JPA solves
or more so ORM solves
Not sure how sharding is related to this
Or vice versa. The real problems come in representation and access efficiency. To me, those rarely matter, because once you choose relationals, you're already slow, the rabbit is dead, move along. Orm doesn't really matter at that point.
relational is the best model imo lol
It's a general issue with mongo. It's fast, but there are good reasons to not use it if you need those features.
ah yeah screw mongo
Why?
If you say so.
have you used it?
Yes?
why is it not better
I'm on my ipad. Not typing all that out.
MySQL is what I'd use if I were running WordPress. That's it.
For every other rdms, postgres.
MySQL and oracle db are not the same creature at all.
Yeah Oracle is better
... if you can afford it and have the space and need for it. I'd choose postgres over oracle, too.
That is the only caveat but Oracle have pumped millions into it
And?
Postgres outperforms it in nearly every way, but pl/SQL is still oracle property.
database scripting is cursed 😵
I don't agree, Oracle DB is known for high performance and scalability
A few years ago yes not now
Tenty years ago. And oracle being fast is just as known.
Don't feed me crap that's in my baileywick, please.
It's my ballpark too lol
Oracle performance is OKAY. Not great. For raw speed, you go with no relational MySQL, lose time support and data integrity but it's fast. If those things matter postgres.
Yeah actually, the latest MySQL is shockingly quick lol
Andif you really want speed but don't need SQL, then you get to consider what needs you have for cap theorem.
I'm saying this because the previous version of MySQL I had a query that took 10 seconds to run, but using the latest it was 1 second
and no underlying difference when I did an analysis on it
Explain plan didn't show a difference?
1 very minor detail
Then MySQL optimized something. Good for them.
Slightly outdated information, but: http://grimoire.ca/mysql/choose-something-else
One thing I really like about mongodb is if you have a complex aggregate, you don't have to create 10+ tables for that one aggregate. Of course, you are giving up normalization for that benefit but we haven't had any issues with it.
We also have a collection that has a parent class with a bunch of sub-types. Mongodb has made that a lot easier rather than having to create a new table for each sub-type.