I like the approach, but infinities can be counter intuitive. See Cantor, Dedekind. The problem is your experiment. We don't say "there are N reals between 0 and 1", we talk about cardinality. The sets (0,1] and (1,3] in R1 don't have "the same number of items" in them; they have the same cardinality.
Please elaborate on the limitations and paths! I'm doing technology selection research and EF Core is currently on the table, would love to hear what you encountered.
One of the most significant for our use case is that composite primary keys do not work with inheritance, which makes it impossible to setup constrained polymorphic relationships.
In general, if you use your database domain (classes) in your business logic, you will have pitfalls when working with your database. This either leads to the N+1 problem (when you use lazy loading), or data structures where a relationship will be null when you try to traverse it.
(Basically, if you use lazy loading, your code will be slow and may require major refactors late in the project life. If you use aggressive loading, your code may have bugs when expected relationships aren't populated.)
I should point out that this isn't purely an EF core limitation! The "correct" approach is to always copy objects from database domain (classes) to business logic domain (classes); but this is often more effort than it's worth.
I'd be really interested to know some recommended methods of realizing having separate db and domain classes. I'm actually in the early phases of a project where I have been using the Memento pattern to save and restore domain entities. I'm about ready to rip it out and switch back to persisting the domain classes directly in the db because it's so tedious. (using EF Core 7 and C#)
Greg Stitt shares amazing training materials freely (he uses them for his undergraduate and graduate courses). His synthesizable HDL methods are really empowering for beginner developers
the first pass is usually an algorithmic digest. the human element is required to recognize a subset of all transactions as requiring further analysis. some transactions require special consideration in either tax or reporting contexts. if every accounting system were a relational database, and every entry had multiple foreign keys to every appropriate classification, we could virtually eliminate CPA's. as it stands each accounting system is bespoke and idiosyncratic. some of them record transactions on sheets of paper.
> if every accounting system were a relational database, and every entry had multiple foreign keys to every appropriate classification, we could virtually eliminate CPA's.
i'd like to hear it confirmed from additional sources but this is what i suspected.
i also imagine those with the necessary skills to formalise these practices are (understandably) not eager to automate themselves out of the value capture loop.
To make it simpler, we could make 12 PM solar noon year-round, use 24 fixed-size hours per day, and just vary our schedules throughout the year so that work and school times make sense.
In other words—leave the clocks alone! It's not the clock that's the issue here, but rather the learned inflexibility about arbitrary work and school hours.
Well, it's complicated in the sense that you couldn't work out the conversion without a computer, but on the other hand it's simple in the sense that the only parameters would be position on the Earth's surface and date/time.
Also, I've read that counting 12 hours from sunrise to sunset was in fact how several ancient peoples did it. They didn't even necessarily count hours at night, only watches.
The way forward might be a synthesis of competing systems / approaches. For instance we could use neoliberal capitalism as a starting point, and (as a society) devote serious resources to addressing harmful effects caused by things like rent seeking and regulatory capture.
