One aspect where rdbms development have forgotten to work is to become a real contender for Access/dBase family.
You will see a lot of people chasing the "Facebook wanna-be" kind of workloads.
I work with small/medium companies (or that are big, but with < 1TB of data). I bet 90% can't pass the first stages of data manipulation:
- Most(all?) rdbms have the same datatypes, mean: Use of nulls (bad) not algebraic types (sad), very unfriendly means to model data/business logic
- Use only SQL, that is impractical to anything bigger than basic queries. I work before with foxpro: I could do ALL THE APP with it, including GUIS, reports, etc. So to say SQL is disappointing is to say the less.
- All the engine stuff is a black box. That is great, until you wanna do your own index, store columnar data, save array or text or whatever you want, plug into the query executor and do your own stuff, etc.
You know, if you have JS and I tell you you can't code your own linked list, you will ditch that quickly. Sometimes, if you db engine allow to plug into the storage I could save my graphs for the only time I need it, instead of hack around putting it in tables or worse: Bring ANOTHER db engine to make my life hard.
Wait! Why?
All that stuff that some put in the middle-wares, model or controllers? In any other product you will reject the tool if you can't, but rdmbs FORCE to use anything else to finish it, despite the fact most run in the same box.
- Everyone add your own auth tables/logic, because the one implemented in rdbms is for a use case that not exist anymore. Then do it wrong, of course
- We are in the http world, but rdbms need something else for that.
- Import/Export data is still SAD.
- Import/Export data outside the few half-backed attempts (like csv, that a lot of time better you do it with python) is impossible in most. Using foreign adapters could work yet, you need to step out the black box, bring the adapter, compile it, install it, then use it. You need to become a C++ developer, despite you pretend to be a SQL one.
That is making thing worse because:
- Not exist a "rdbms" packager managers.
Look, how great if you just:
db install auth-jwt
db install csv-import
end. Like everyone else
- Making of forms and reports. You can bet any company (even users!) will kill if their dbs allow to create reports and forms. Yep, alike access. Yep, that is because access is still a thing with the most weak db engine in town.
- You wanna allow to send emails, connect to external apis, call system services, etc.
But why? Is not that problematic? Well, if you JS (a language FOR THE BROWSER) allow it, why not your db? I live in that world before (foxpro) and it work GREAT.
---
A lot of this stuff is because the rdbms are look with a too narrow POV. Is crazy: People use half-finished NoSQL engines and are happy making his own query engine, yet talking about do else than SQL (or: plug into the query parser so i enhance it) will sound crazy to some.
Rdbms get leap-frog by NoSQL because until very late, get stuck in a mindset and use cases of the 80s.
Not exist ANYTHING that say you rdbms must be like all the others.
Broad the view is what, I think, rdbms need to do to get invigorated, and considering that are also performant, and very good, then will made to conquer the world!
You will see a lot of people chasing the "Facebook wanna-be" kind of workloads.
I work with small/medium companies (or that are big, but with < 1TB of data). I bet 90% can't pass the first stages of data manipulation:
- Most(all?) rdbms have the same datatypes, mean: Use of nulls (bad) not algebraic types (sad), very unfriendly means to model data/business logic
- Use only SQL, that is impractical to anything bigger than basic queries. I work before with foxpro: I could do ALL THE APP with it, including GUIS, reports, etc. So to say SQL is disappointing is to say the less.
- All the engine stuff is a black box. That is great, until you wanna do your own index, store columnar data, save array or text or whatever you want, plug into the query executor and do your own stuff, etc.
You know, if you have JS and I tell you you can't code your own linked list, you will ditch that quickly. Sometimes, if you db engine allow to plug into the storage I could save my graphs for the only time I need it, instead of hack around putting it in tables or worse: Bring ANOTHER db engine to make my life hard.
Wait! Why?
All that stuff that some put in the middle-wares, model or controllers? In any other product you will reject the tool if you can't, but rdmbs FORCE to use anything else to finish it, despite the fact most run in the same box.
- Everyone add your own auth tables/logic, because the one implemented in rdbms is for a use case that not exist anymore. Then do it wrong, of course
- We are in the http world, but rdbms need something else for that.
- Import/Export data is still SAD.
- Import/Export data outside the few half-backed attempts (like csv, that a lot of time better you do it with python) is impossible in most. Using foreign adapters could work yet, you need to step out the black box, bring the adapter, compile it, install it, then use it. You need to become a C++ developer, despite you pretend to be a SQL one.
That is making thing worse because:
- Not exist a "rdbms" packager managers.
Look, how great if you just:
end. Like everyone else- Making of forms and reports. You can bet any company (even users!) will kill if their dbs allow to create reports and forms. Yep, alike access. Yep, that is because access is still a thing with the most weak db engine in town.
- You wanna allow to send emails, connect to external apis, call system services, etc.
But why? Is not that problematic? Well, if you JS (a language FOR THE BROWSER) allow it, why not your db? I live in that world before (foxpro) and it work GREAT.
---
A lot of this stuff is because the rdbms are look with a too narrow POV. Is crazy: People use half-finished NoSQL engines and are happy making his own query engine, yet talking about do else than SQL (or: plug into the query parser so i enhance it) will sound crazy to some.
Rdbms get leap-frog by NoSQL because until very late, get stuck in a mindset and use cases of the 80s.
Not exist ANYTHING that say you rdbms must be like all the others.
Broad the view is what, I think, rdbms need to do to get invigorated, and considering that are also performant, and very good, then will made to conquer the world!