I agree with you, specially on the source control part. Issue here is that some companies already implement this kind of design and it's very hard change.
Then if using a relational database as storage, might be just a good to use a very fast nosql database, even if you lose the relational part?
About your side-note, yes, I know that. But you know what I meant :)
Yes, it is really common to see multiple legacy apps share the same database and use the shared data for different purposes. (This is called an Integration Database.) It creates a really unfortunate situation where it becomes increasingly difficult to make changes for fear of breaking one of the apps. In a system like this, new functionality usually means new tables because the risk of changing existing data is too great.
My solution for that is typically to insert an API (could be a service or a library) in between the database and the apps, and gradually migrate the apps to use the API. At least in the API you can have a better overview for how all the data is modified. Once apps are no longer accessing the database directly, you can make structural changes to the database with a decreased risk of breakage. As long as the API contract with the app remains the same.
Stored procedure isn't a purely relational database feature. So skipping them doesn't imply you should use NoSQL. Relational still does set-based constraints (unique constraints, set membership) really well whereas NoSQL databases are generally not good at those. The place where NoSQL really shines from a coding perspective is when you have a hierarchical object. Splitting it into a lot of child relational tables and reconstructing that data back to objects is very painful and is the main reason ORMs exist. But it's super easy in NoSQL because you just load/store the whole thing as one object. Many relational DBs can be used as key-value storage too nowadays (e.g. Postgres has json/jsonb types, as well as hstore). The other main reason to use NoSQL is for scaling out. Most relational databases will only scale up. There are also certain types of NoSQL database better for certain jobs, like graph databases.
I wasn't trying to be rude with my side note. I literally wrote business logic in controllers and code-behind pages for many years. Over time it became really hard to untangle the business code from all the integration code. I still face this problem with some legacy apps that haven't justified a rewrite yet.
Yes, we are exactly planing to do that next year. It'd require lots of work, mind you it's about 300 tables and 500 Stored procedures.
My plan is similar than yours, which makes me relax a bit thinking that it's the way to go :)
I never found your side note rude in any way, but the other way around.
You know, maybe there is someone who is doing that might read it and think about it. :) Side notes with good knowledge are a must in this kind of conversations.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you, specially on the source control part. Issue here is that some companies already implement this kind of design and it's very hard change.
Then if using a relational database as storage, might be just a good to use a very fast nosql database, even if you lose the relational part?
About your side-note, yes, I know that. But you know what I meant :)
Yes, it is really common to see multiple legacy apps share the same database and use the shared data for different purposes. (This is called an Integration Database.) It creates a really unfortunate situation where it becomes increasingly difficult to make changes for fear of breaking one of the apps. In a system like this, new functionality usually means new tables because the risk of changing existing data is too great.
My solution for that is typically to insert an API (could be a service or a library) in between the database and the apps, and gradually migrate the apps to use the API. At least in the API you can have a better overview for how all the data is modified. Once apps are no longer accessing the database directly, you can make structural changes to the database with a decreased risk of breakage. As long as the API contract with the app remains the same.
Stored procedure isn't a purely relational database feature. So skipping them doesn't imply you should use NoSQL. Relational still does set-based constraints (unique constraints, set membership) really well whereas NoSQL databases are generally not good at those. The place where NoSQL really shines from a coding perspective is when you have a hierarchical object. Splitting it into a lot of child relational tables and reconstructing that data back to objects is very painful and is the main reason ORMs exist. But it's super easy in NoSQL because you just load/store the whole thing as one object. Many relational DBs can be used as key-value storage too nowadays (e.g. Postgres has json/jsonb types, as well as hstore). The other main reason to use NoSQL is for scaling out. Most relational databases will only scale up. There are also certain types of NoSQL database better for certain jobs, like graph databases.
I wasn't trying to be rude with my side note. I literally wrote business logic in controllers and code-behind pages for many years. Over time it became really hard to untangle the business code from all the integration code. I still face this problem with some legacy apps that haven't justified a rewrite yet.
Yes, we are exactly planing to do that next year. It'd require lots of work, mind you it's about 300 tables and 500 Stored procedures.
My plan is similar than yours, which makes me relax a bit thinking that it's the way to go :)
I never found your side note rude in any way, but the other way around.
You know, maybe there is someone who is doing that might read it and think about it. :) Side notes with good knowledge are a must in this kind of conversations.