Monday, 11 May 2009 13:09

Not all databases are created equal

Software companies hurt their products by writing database engines when they’re not a database company, and by marketing teams who don’t understand why the database is important.

Most every business application uses a database. That makes sense; apps must store data. You want your information to be there even if you log off. You want to collaborate with colleagues. Even the law requires certain information to be retained for years.

Yet there are an awful lot of companies out there who fail to use a solid database platform or who have marketers that can't articulate what their database is (and don’t understand why I care.)

There are even software execs who delude themself their "just another database" is something far more than it is.

When I'm looking at software it's not just a matter of a business evaluating its functionality. Obviously, function is important. You don’t want a financial package that can’t raise purchase orders, for example.

However, there are also many technical considerations any company beyond a certain size will be looking at too.

Just four I keep in mind are how well the package slots into an enterprise architecture, how easily we can extract ad-hoc data on demand, how well it scales and how well it operates over a wide area network - if at all.

Often times these four matters come down to the database technology used. Let's be frank, a lot of software houses are really letting themselves down here.

Sometimes it's a matter of skimping on costs. You see this when the software stores its data on a file share. That's a low cost development solution which accordingly yields low quality returns.

Software that saves to a file share is a never-ending source of problems. You have to map a drive letter which sounds insignificant but keep in mind these are a finite resource.

You will have problems with drives failing to map from time to time, as happens for varying reasons, and which result in help desk trouble tickets, application unavailability and more.

Additionally, a file share is going to give dismal performance over a WAN. As soon as you want to run the app in two different offices your users will complain it’s too slow. You may get forced into terminal services whether that suits your plan or not. Sometimes the app won't even perform satisfactorily on the local area network!

This isn’t my only gripe. What about databases from non-database companies?

Make no mistake; there are good reasons why a terminal environment may suit your business. What I don't like, though, is being forced into it by bad software. Frankly, I think if a program requires running terminally to perform adequately then it's a badly written program.

Some examples of programs like this are Sybiz, TimeMinder and ServiceMaster.

Of course, not all bad software is just because the company was cheap.

Another problematic database comes in where the vendor has clearly had money to burn and opted to write a proprietary database system instead of focusing time and effort (including debugging time!) on the core product.

Now, I don't want to stifle innovation here but unless your line of business is databases, don't go writing a database.

In these instances, data is almost certain to be impenetrable and most certainly there won't be any ODBC driver or support for external querying, analysis and reporting tools.

MicrOpay Payroll Manager is one such example. Another is WorkDesk and even MYOB falls into this category, although it does provide limited ODBC functions for a fee.

I expect to be able to write any custom report, or perform any analysis or trending on our data. If a product restricts this then I have a real problem with it.

Whether a software vendor is big or small, budget constrained or not, they're doing me no favours when they neglect to use a database or they think it smart to write one.

They also don't help themself when the marketing people can't articulate their own product.

This can come in the form of WorkDesk responding to my queries by saying "We use a database written in C" - which conveys no useful information at all. The same when GEMMA refers to its use of an "SQL data file."

There are even multitudes of marketeers spruiking about their "SQL" database. This is similarly a term devoid of meaning. Do they mean SQL Server? MySQL? Heck, any database that can accept SQL queries be it ANSI compliant or not?

I must give praise to MYOB who are currently re-engineering their product to use SQL Server but even then their early literature referred to “SQL.NET” which was a similarly meaningless term. Happily, after I challenged them, they now talk about a .NET application using an SQL Server back-end database.

This immediately communicates to corporations the technical landscape required and also silently conveys the higher capabilities you can reliably expect.

Other companies learned this lesson too, with MicrOpay Meridian and Quickbooks now having SQL Server versions, to their customers' satisfaction, and no doubt to a decreased development cost of their own.

The lesson is simple: if you’re a software house and databases aren’t your core business then don’t write one! Secondly, if you sell software, make sure you know the name of your technology. The customers do care.


You cannot afford to miss this Dell Webinar.

With Windows 7 support ending 14th January 2020, its time to start looking at your options.

This can have significant impacts on your organisation but also presents organisations with an opportunity to fundamentally rethink the way users work.

The Details

When: Thursday, September 26, 2019
Presenter: Dell Technologies
Location: Your Computer


QLD, VIC, NSW, ACT & TAS: 11:00 am
SA, NT: 10:30 am
WA: 9:00 am NZ: 1:00 pm

Register and find out all the details you need to know below.



iTWire can help you promote your company, services, and products.


Advertise on the iTWire News Site / Website

Advertise in the iTWire UPDATE / Newsletter

Promote your message via iTWire Sponsored Content/News

Guest Opinion for Home Page exposure

Contact Andrew on 0412 390 000 or email [email protected]


David M Williams

David has been computing since 1984 where he instantly gravitated to the family Commodore 64. He completed a Bachelor of Computer Science degree from 1990 to 1992, commencing full-time employment as a systems analyst at the end of that year. David subsequently worked as a UNIX Systems Manager, Asia-Pacific technical specialist for an international software company, Business Analyst, IT Manager, and other roles. David has been the Chief Information Officer for national public companies since 2007, delivering IT knowledge and business acumen, seeking to transform the industries within which he works. David is also involved in the user group community, the Australian Computer Society technical advisory boards, and education.



Recent Comments