August 30, 2021 at 12:00 am
Comments posted to this topic are about the item Eyes Wide Open
August 30, 2021 at 10:34 am
Really good editorial!
I listened to a lecture on the insurance industry where the speaker said that when you buy insurance you are really paying for someone else to bear the risk.
So it is with hiring consultants. Some have been very good. Many have made recommendations that were OKish and might have been reached without their help. That wasn't the point. I see the use of consultants as a form of insurance. We are outsourcing a large proportion of the decision risk.
I perceive choosing the tech that your competitors or "the big guys" use as also a risk management approach. The Gartner hype cycle is an embodiment of Fred P Brooks "Silver Bullet" theory. A technology may be game changing but when you see an overnight success you probably don't see the years of blood, sweat and tears that looks like overnight success.
August 30, 2021 at 12:33 pm
Very good article, Steve. Where I currently work, I've seen a couple dozen databases written for home grown applications with a purpose in mind. And unfortunately, we never really consult the DBAs. For example, my boss who insists upon doing the database designs, uses TOAD (a fine tool, don't get me wrong), but he makes some odd choices, when he designs databases. All primary keys must be BitInts, for some reason. I shudder to think of a dropdown in an application that will render 2^63 number of rows from a lookup table. Another example, I'm working on an app now that was designed by someone who I never met. That developer decided to not put primary or foreign keys anywhere.
I wish we would utilize the DBAs more. I can't understand why we don't.
Rod
August 30, 2021 at 1:34 pm
My basic advice to a startup would be:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 30, 2021 at 3:46 pm
My basic advice to a startup would be:
- Don't build up your own data center - Let cloud providers like Azure and Amazon do this for you at a fraction of the time, cost, and risk.
- Hire professional database engineers. Sure, your best friend from university may know "a thing or two" about databases and you owe him one - but that doesn't cut it when it comes to developing something that will scale at the enterprise and internet level.
- Regardless of whether it's a web application, mobile app, or internal BI reporting system - don't let the front-end application interface with the database directly. Don't even let them have a database login. All data access should be abstracted through a service-oriented architecture. Not having functional dependencies between the front-end and back-end means the database engineers can refactor the data model or even migrate to a different database platform with minimal effort and conflict.
I really hear ya, Eric, especially on that third option. Even in large organizations I've seen every internal app doesn't use any data or business layer. Everything is handled in click events with tight coupling between all modules and the database. They will obfuscate database connections or use Windows Authentication, but other than that it depends too much upon the database schema being too well known to the application. Too tightly tied to the app. If ever the database has to change or it is replaced with a different data storage of some kind, that necessitates bringing the application down for long periods of time.
Kindest Regards, Rod Connect with me on LinkedIn.
September 1, 2021 at 12:50 pm
Regardless of whether it's a web application, mobile app, or internal BI reporting system - don't let the front-end application interface with the database directly. Don't even let them have a database login. All data access should be abstracted through a service-oriented architecture. Not having functional dependencies between the front-end and back-end means the database engineers can refactor the data model or even migrate to a different database platform with minimal effort and conflict.
I don't understand why you need the service-oriented architecture - it only seems to add complexity.
If you have a mechanism for analysing application code to discover database dependencies then any changes to the database will be immediately apparent.
If you have the SOA then you have to analyse both the dependencies between the application and the SOA and between the SOA and the database. This just looks like a lot of extra complexity, extra effort and a much greater possibility of error.
By introducing an SOA you throw away the flexibility of access which is the whole point of having a SQL-DBMS rather than a set of subroutines (which is what an SOA is).
If ever the database has to change or it is replaced with a different data storage of some kind, that necessitates bringing the application down for long periods of time.
There is no reason why changing the database structure should lead to downtime if you are doing change and version control properly. Changing the data storage certainly won't - the whole point of an RDBMS is that you only interact with the logical layer. The vendor of the DBMS could completely change the storage mechanism of their RDBMS without any impact on existing applications. That's one of the many reasons that SQL-DBMSs have become dominant and will continue so for the long foreseeable future.
September 1, 2021 at 4:14 pm
I think the concerns over SOA with regard to changing structure are things like changing tables. However, I tend to agree with Will that we can make these changes without disruption.
Application code needs to follow good practices. The main ones are:
I ought to be able to refactor the table without breaking app, and certainly I can add columns. If I need to change something, i.e. full name to first name/last name, this isn't one deployment. I use a couple of stages and triggers to sync data. In the last deployment, I remove the full name column.
My view is that often people complaining about complex deployments are a) unwilling to approach things in steps, b) don't deploy often enough, and c) feel that every changes needs to be in one deployment.
September 1, 2021 at 8:14 pm
I think the concerns over SOA with regard to changing structure are things like changing tables. However, I tend to agree with Will that we can make these changes without disruption.
We often forget that a RDBMS has its own method of abstracting the interface with the application from the underlying data structure - namely views.
The view design needs to be given the same attention as the database design, to avoid views that introduce redundancy or hinder performance.
The trouble with middleware is that the methods employed seem to change frequently and it lacks the sound theoretical basis of the relational model.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply