dollarsvast.blogg.se

1. #Universal database vs eav modeling how to
2. #Universal database vs eav modeling manual
3. #Universal database vs eav modeling software
4. #Universal database vs eav modeling Offline

I agree that it's very important to not let the physical schema leak into the rest of the system, and to have a strong conceptual model (aka entities and relations). > forces your design towards the entities themselves

#Universal database vs eav modeling Offline

Ping me offline if I can help explain any more. That kind of advice ain't happening in an HN thread.

#Universal database vs eav modeling how to

So the heuristics you'd get would be perfect world completed apps, and what you really need to know is, well, how to develop software. Instead, what's needed is how to gradually get from here-to-there in a complex world without getting lost. (Of course, they should be aware of them!). But at the level of complexity we have now, it just doesn't seem realistic to be teaching people the perfect way to do things. It even worked great in larger apps with tight control. This idea worked great in classrooms, worked great in personal and small apps. Then came a ton of CASE tools, now ORMs, and so forth, all in an effort to get us back to easily owning and changing data schemas.īut the real problem was there all along we just didn't realize it: thinking you knew everything and could manage it. If I had to generalize, everything got more and more complicated and the assumption that you could grab the entire application in your head easily and change it was no longer true. This started falling apart really quickly, though, with folks talking about impedance mismatch just a few years after relational databases went mainstream. So changes to the schema involved a finite and easyish-to-do set of practices. Back in the day, you controlled the app, the machine, the storage, and the code. I think the thing to remember when you're learning various architectures, from database schemas to build pipelines, is that many times the people teaching you are teaching you from a position of having a completed project and then looking back on the lessons learned and applying some heuristic-making to them.įor instance, if you look at database normalization, which I started with when I started coding, it makes total sense for a small-ish project. Unfortunately, and I apologize for sounding difficult, this is still far too broad to gain traction on. I get what you're saying, that by moving to the meta level we can talk about heuristics and patterns of development. but the fear of this eventuality should not automatically translate into turning the development process on its head.) (I understand that data models that need changes other than adding new columns or new sub entities can be painful to refactor. That is then considered holiest of holies. The models, when sufficiently complete, are printed in large format and pasted on walls for all to see daily. I use a good ER modeling tool to avoid frustrating myself when large changes are needed for my model. Then, identifiers, business keys and other coding formats are also determined very early on in the project.Īll of this before you even choose a front-end framework or the people's favourite ORM library. Then, cardinalities and ordinalities will be known the moment you understand the objects relationships too (Can a client with product A also have product B? etc). a great way to start is to look at what reports users might need.

#Universal database vs eav modeling manual

What to persist and what not to persist are also discernible from existing manual business processes and the documents operational staff use daily (many of these are legal documents like tax invoices, contract confirmation, mandates and policy agreements etc.

You have to look for them first before you do anything. In my experience: the objects from the problem domain will always have certain immutable relationships with each other right from the beginning.

#Universal database vs eav modeling software

(I see a lot of this thought these days and I'm genuinely worried we are about to swing the pendulum of software design into the dark ages where focus from the data model is taken away in favour of convenience of process design, front end design and data access frameworks). I don't buy this argument, with due respect. >I agree, and I've come to the conclusion that you should avoid designing a database schema until you have some clear understanding about how the application you're persisting data for will be used.<