Register for a free consultation!
The Power of Any Application is in the Database
1/16/2017 3:44 PM
If you've been following along, you recognize that most of what we do here at
is healthcare related due to having a sister company in the healthcare sphere:
. Last Thursday's post "
One Application to Rule Them All
"was the exception that proves the rule. We examined Sentia's Object Relational Mapper (ORM) and why it is different and better, but not really the underlying philosophy behind it. Today, we are going to examine that philosophy.
There are only two kinds of code that get written: Procedural and Set-Based. All of your "Hello World" programs and your "for each" and "i+=1" (or "i=i+1") and Object Oriented (OO) and 95% of everything you have been taught is procedural. It is a "put this value in this variable and loop this many times" kind of thing. Java, in all of its various flavors is probably the world's most popular language. It doesn't even guarantee a database at all, and there are hundreds of ways to "get around" the need for a database, making Set-Based programming that much more rare. Set based code, however, doesn't (and shouldn't) work this way. Set based code says "give me a filter and let me dump all the data through it and whatever is left is a match."
Here is a metaphor we have used before. Your Drill Instructor orders you to 'get him a rock.' Having heard this story before and knowing that things will go more easily if you ask a few question, you ask "what kind of rock?" He states he needs a rock about the size of a quarter, Amy kind of material will work, but it is the over all size that matters, but he needs as many that match the criteria as you can find.
If you use a procedural methodology, you go grab a bag, a quarter and a pair of tweezers and you start picking up every rock you can find. If the rock is about the size of a quarter, put it in the bag. Sounds like it will work, but it isn't very efficient. Set-Based coding is far more efficient. being a smart guy you find a couple of pieces of plywood and drill holes in both; one a little larger and one a little smaller than your proverbial quarter. You then dump
the rocks through the larger filter filtering out the larger rocks, then you dump the tailings through the smaller filter and what is left fit the requirements.
Your goal as a developer is to write as much of the code for your new application in Set-Based code as possible. Another way to say this is 'as little procedural code as possible.' At that point the procedural code simply becomes an object oriented representation of your database, and therefore, you don't need nearly as much of it.
Yes, trips to the database are expensive. When you have lookup data that doesn't change often,you should probably figure out a scheme to cache it in memory on the web server, so you only have to go to the database once, or at least infrequently. These kinds of lookup values are things like color, or gender. (In 2017, gender might be more fluid than we initially thought, though)
There are some special database considerations. Your database should be additive. That means that you don't update records, you add new records. You don't delete records. Deletes are amazingly expensive and an update is merely a delete and reinsert. You should have separate tables for lookup values. See discussion above about caching. You should institute a primary key that has no intrinsic value. you should never show that primary key to anyone, particularly the user lest s/he
it an intrinsic value. I use an integer datatype, you can make an argument for GUIDs. You should enforce data constraints to describe the relationships between the various tables (entities) in your database. You should add a foreign key to the many side of a one to many relationship and enforce the constraint between it and its primary parent.
Document storage databases, like NoSQL, are becoming increasingly popular. Don't use them. Instead save the document in the database itself as a Binary Large Object (BLOB) or on the file system with a pointer in the database back to the document. Store the metadata, maybe including the text of the document itself, in the database for fast, reliable retrieval.
Big Data is a buzzword used to clean the pockets of those who don't understand relational databases. Hadoop and Map Reduce both use procedural languages to loop through (like your private with a quarter and a pair of tweezers above) 'unstructured' data and pick out what is necessary. Instead, we should structure that data, and use our tried and true Set-Based programming language on it. While structuring the data will take about the same amount of time as running that first Hadoop query, the second will run orders of magnitude faster and you won't have to go buy an entire infrastructure to support "Big Data." Actually, there is no unstructured data, just data that hasn't been structured yet, and therefore there is no such thing as "Big Data."
So now that we have reduced the procedural needs of our application down to simply representing the database in a way that our user interface can understand and manipulate, we have gained the ability to generate all the code necessary for a new application given only a solid database design. We know this is true, because we have done it. We have developers who single-handedly are pumping out two completed applications every week. This is so fast and inexpensive that we are generating prototypes for our clients to log in and use free of charge. Then, and only then, do we start doing the deep dive on requirements gathering, since the client has a baseline of what's possible and in what amount of time, and scope creep literally goes away.
So yes, Virginia, this is true. We have this tool. It works and it works better than your Entity Framework, nHibernate, LINQ, or whatever else you are using. It is more secure than anything else on the market and that security is built in, and that means generated.
This is the future of software. You can call it AI if you like, but it isn't. Yes, you give it different inputs and it gives you different answers, but AI (and machine learning and deep learning)doesn't truly, and may never exist.
In conclusion, we've shown you why the database-centric approach is the best. We've demonstrated why very few use the database-centric approach. We've shown why Relational Database Management Systems (RDBMSs) are superior to document-based or "Big Data" approaches. We've shown that we alone have the ability to generate applications based on good database design.
If you go back to our article on Thursday, that we mentioned above, maybe it will make more sense in light of this explanation.
Maybe you should give us a call.
Mission and Values