Tired of CRUD? What about learning CRA (Create Read Append)?
There are so many places where people did add "time" information to CRUD DBs because of the 'U' and 'D' that it's not even funny.
Learn a CRA DB and go apply to companies using today technologies that shall be used in the future mostly everywhere.
Most CRUD DBs I've been working with would have had absolutely zero space issue had they been using a CRA DB. And this would have solved so many issues. The only downside of "CRA vs CRUD" is that CRA DBs tend to be bigger (not than the CRUD one who did poorly re-model time that said)... But with today's hardware and especially memory growing up so fast and going down in price so quickly (the two being related but not identical), it's really not a problem anymore for 99.99% of the companies out there to simply store facts in a "ever growing, append-only" DB.
Just an example: there are many times where someone up the chain asks for some information and you either have to ask the DB guys to give you a backup of the prod DB at "time X" on some DEV/PREPROD environment or you have to go fetch business information by parsing logs.
These are two major fails. And they're mostly related to the fact that most CRUD DBs are modeled as "non factual". The 'U' and 'D' are irreversible operation losing business information and developers time.
So learn about CRA DBs like Datomic (which you can, btw, back with a SQL DB like PostgreSQL) and then go apply to companies who "saw the light".
There are so many places where people did add "time" information to CRUD DBs because of the 'U' and 'D' that it's not even funny.
Learn a CRA DB and go apply to companies using today technologies that shall be used in the future mostly everywhere.
Most CRUD DBs I've been working with would have had absolutely zero space issue had they been using a CRA DB. And this would have solved so many issues. The only downside of "CRA vs CRUD" is that CRA DBs tend to be bigger (not than the CRUD one who did poorly re-model time that said)... But with today's hardware and especially memory growing up so fast and going down in price so quickly (the two being related but not identical), it's really not a problem anymore for 99.99% of the companies out there to simply store facts in a "ever growing, append-only" DB.
Just an example: there are many times where someone up the chain asks for some information and you either have to ask the DB guys to give you a backup of the prod DB at "time X" on some DEV/PREPROD environment or you have to go fetch business information by parsing logs.
These are two major fails. And they're mostly related to the fact that most CRUD DBs are modeled as "non factual". The 'U' and 'D' are irreversible operation losing business information and developers time.
So learn about CRA DBs like Datomic (which you can, btw, back with a SQL DB like PostgreSQL) and then go apply to companies who "saw the light".