Databases: 50 years of stupidity


Database conventions are not best practices.  Database naming conventions are based on random ontological concepts.  Ideas about what constitutes an entity are misdirected.  Programmers know nothing about what a class or an object is or how to name them.  Hierarchical, Relational and Network databases have maintained a persistent and ignorant set of practices that the information technology intelligencia have followed mindlessly.  What we have after 50 years is a brute force patchwork of bad design practices and mediocre engineering that continues to work within the same set of assumptions.  It’s a product of the inertia of intellectual lethargy that dominates not just the technological world, but the world that uses technology in general.  Workers are too busy being inefficient and ineffective to improve their business practices.  They jump at silver bullet solutions that promise results without change.

Database people have never understood data.  Programmers have never understood data.  They have instead tried to please everybody’s ontological misconceptions with grotesque architecture and then shoehorn it all into a physical processor that is about as progressive and efficient as the internal combustion engine.  Eco-nut technologists like to use buzzwords like “organic” to describe the chaotic crap they are producing on the web.  It isn’t organic, its a massive slum composed of any piece of detritus the occupants can build with surrounding a district of monolithic towers of gross excess and shameless waste.  Google’s motto is “Don’t be evil.”  Has any company ever considered having the motto, “Be good”?  The more I work with corporations the more I recognize that goodness is discouraged and evil is whatever the corporation says it is.  If you work for anyone you are part of a Milgram experiment and you are delivering those electric shocks everyday under the direction of psychopaths.  The merit you get promoted for is based on your willingness to flip those switches more than anyone else.  Having a conscience is deemed unprofessional and grounds for termination.

This is the environment within which real innovation has to work.

Hungarian Backwords Notation, a naming convention by Charles Simonyi, has been abused and bastardized by programmers and database administrators with no understanding of semantics, which is most of them.  Consequently, it has been rejected by a large portion of the IT community.  Not even Microsoft knew what it had.  I fought with Simonyi’s concept for years and applied it in several working applications successfully against massive resistance.  The more I worked with it the more I realized that Object Oriented Programming was based on a completely false ontology.  The metaphors were completely wrong.  And the Unified Modeling Language entrenched the misconceptions even further.  Information technology is spawning increasing complexity without any appreciation for underlying order.  The order was datatypes.  There are only a handful of Classes and they are datatypes. The English are backwards, not the Hungarians.

If the world was looked at as a collection of datatype classes the entire philosophy of data and programming and systems would have to change.  Objects do not have properties, properties have objects.  And there are only a handful of properties.  I’ve realized this and it has changed my perspective of data design forever.  Throw away your OOP and your Data Model textbooks.  They’re crap.  Google, Apple and Microsoft are not the future.  Einstein had a better grip on reality than Turing ever did.  The typical mind, including the IT mind, still thinks elephants are bigger than the moon.

Related Links:

Approach and Reapproach


This is an interesting site about mazes using graphical techniques. When I look at the examples I am reminded of my approach and reapproach of core concepts to have new insights. This a key element of mental flexibility. It is not wrong to attempt again and again to solve the same problem. It is wrong to attempt again and again to solve the same problem with the same approach.  It should also be recognized that differences in problem and approach can be subtle.

Formatting PL/SQL like SQL

In going through reams of PL/SQL code it dawned on me that procedural language is often formatted differently than structured query language in the same code sample. I decided to take a shot at formatting procedural language code like SQL and I like the result.

	var1 number(9) 	:= 0;
	var2 number(9) 	:= 0;
	var3 number(9) 	:= 0;
	var4 number(9) 	:= 0;
	var5 number(9) 	:= 0;
	var6 number(9) 	:= 0;
	var7 number(9) 	:= 0;
	var8 number(9) 	:= 0;
	var9 number(9) 	:= 0;
	if 	var1 	= var2
	and 	var3 	= var4
	or 	var5 	= var6
		while 	var1 	< var9
		and 	var2 	is null
		or 	var4 	is not null
			select 	a.col1
			into 	var6
			from 	table1 a
			, 	table2 b
			where 	a.col1 	= b.col1
			and 	a.col2 	= var7
			or 	b.col2 	= var8;

			var1 	:= var1 + 1
		end loop;
	elseif 	var1 	= var2
	and 	var1 	<> var3
	or 	var1 	<> var4
		into 	table3
		( 	col1
		, 	col2
		, 	col3
		( 	var1
		, 	var2
		, 	var3
		var9 	:= 100;
		if 	var4 	is not null
			var8 	:= 100;

Note that I am using ten character tabs throughout the code and formatting and aligning as I would with SQL. I find the conditional structures in the IF and WHILE statements much clearer this way.

*Footnote: I recently used the TOAD formatter command and have found it surpasses my own standard for formatting. If you have TOAD I highly recommend the use of the formatter for all code. The saving in effort for the maintenance people that follow in your development footsteps is well worth it.

formatting plsql like sql formatting plsql like sql formatting plsql like sql

Code Slobs

I have been having quite a time at work these days as I have been assigned the task of doing an impact analysis on the addition of a column into the database schema.  I have found myself without documentation and having to go into the source of hundreds of programs and scripts looking for the implications of the change.  The code is completely unformatted and trying to rectify the situation to save my bleeding eyes has been hell.

What obstacles do I face?  My Team Leader says she doesn’t look at code so she doesn’t care what format it is in.  My Senior Oracle Developer says he formats all his code, but he doesn’t consider code formatting important.   The remaining development team writes functioning code, but has no education in how to format PL/SQL so it’s readable.  In otherwords, I am surrounded by Code Slobs.

How do you deal with code slobs?  First, automation.  I have persuaded all of them to use the TOAD code formatter in the future so people without TOAD can make some sense of their product when doing maintenance.  Second, roll up your sleeves and clean up the legacy code.  I have to go through the code looking for the impact of a column change anyways, so along the way I am formatting all the code I read.  I know there will be more impact analysis tasks and code maintenance, so I am hoping to make it easier for future code readers and maintenance programmers.

So, look out code slobs, I am going into every nook and cranny and sorting out the detrius,  so someone, anyone can have a better chance of giving your work a longer life span, simply by making it readable.