4 ms·
Ask HN: please help me understand latest trends in database design
I'm naturally a front-end guy but database design and back-end dev has piqued my interest the last few days and I'm lingering very confused. I'd like to fully grasp these concepts so my head doesn't hurt anymore.
I'm used to dealing with an ORM like active record. When I imagine my user objects through rails I picture an object of a person being related to a row in the people table. Ok basic.
So, I read that non-relational databases like mongodb aren't just cool because they're "fast with big data" but they're also cool because they apparently make developing more natural with an oop language (why?). Then I also read that most design patterns probably aren't truly relational. Ok, this is where I get lost.
1) What are some fundamental examples of relational design and non-relational design? 2) similar to above, what are examples of structured data vs unstructured (is this just rephrasing above?)
So, given those things I feel (in my immediate ignorance) that almost every type of project I've attempted to model against has been relational. But maybe I'm just using semantics over technicality. For example, posts and comments. Relational to each other. Add users in there. it seems most apps these days have data that is always useful to reach through other data/objects. That's relational isn't it?
How about something describing something less typical.
Let's say I was building a workout tracker app. I have users, exercises, workouts, routines and log_entries.
I create a routine to group workouts. A workout is a group of exercises. I record my reps and weight through log entries for my exercises. Is this relational data or non relational? Would mongo be great for modeling this or awful?
I hear things like statistics come into play. How does that affect the above example? What statistics are people usually speaking of?
Let's say I added tracking other things, like a users weight, height, body fat and so on. How does that affect things?
Thank you for taking the time to help me understand.
Edit: can anyone explain why it may be easier to develop for one over the other. Is using something like mongo more agile both because it "clicks" more once you "ge it" and also because you don't need to run migrations?
Another thing, when using an abstraction like an ORM - does it really matter? If so when? To me the initial value would be the ease of querying data and modeling my objects. Whatever lets me do that easier is what I'd be happy with. I truthfully do find myself scratching my head a lot when trying to model data.
- kellros 14y agoWhat web framework are you using? It's possible to model inheritance/abstraction within database design but it's not always optimal. You can 'extend' an existing table by specifying the child identifier as a primary and foreign key referencing the parent table (this is called 1 to 1 mapping). Most of the time when you see 1 to 1 mapping you won't see it, because in relational databases you add those columns to the same table. There are some scenarios where it makes sense to split the table into two tables, such as a User and an Account table (AccountId = UserId), so you can better model the relationships. Most people would advise against it and tell you to denormalize those tables (put everything on the user table), but if you use an orm that does class-per-table mapping it really reduces friction (ex. anything referencing an Account is accessable from an account, everything referencing a User specifically won't be directly accessable via the Account). There's also a difference between key-value stores and object-oriented-databases (both being NOSQL). The reason why using NOSQL is 'closer' to your actual objects is because you would be storing actual objects (they get serialized into a graphs and stored). I'd also suggest you check out Brewer's CAP Theorem: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem http://www.julianbrowne.com/article/viewer/brewers-cap-theor...
- opendomain 14y agoWhen you write your app, you are choosing a programming language to express your ideas. This is a MODEL of what you want to do - for example if you code using Object Oriented Design, you may have a Workout object and an Exercise object. So your design uses "HasA" inheritance - a Routine HasA Workout. But when you want to store the data these objects contain in a database, the model is now Relational. You have one record for the Routine and multiple for the Workouts. Because the MODEL is different, you get impedance when you move data between the layers. An ORM is an Object-Relational Mapper that helps reduce this friction, but it can still have problems especially when you have many-to-many or circular relationships. NoSQL datastores allow you to save your data very closely to how you model it in your application and you do not need an ORM. However, you do not get it for Free you have simply decided to move the logic of maintaining a consistent state into your application. Also, as your application evolves, it will become more difficult to manage your changes in your schemas because you have only deferred the cost change without following a good software development process, your system may spaghetti code very quickly. If you want to learn more contact me at Ric AT NoSQL dot com