|
Spring 1997
|
For the application developer who is accustomed to creating applications with Pick or a Pick-like data-base product, thinking about the database and how it integrates with your programs is a bit of a non-event: it’s just there!
However, when it comes to creating applications under Windows we are presented with a somewhat different picture: here the database side of an application is very much a distinct separate entity. This presents us with both a problem and an opportunity. The problem is that the application developer has to think an awful lot more about their database usage; the opportunity is that you're free to choose the database product that best suits your requirements.
Great, you think, I'll just apply the grey matter a little harder and the world is my oyster. Well, maybe, maybe not. You see the snag is that in order to keep your database options open, you’ll probably have to opt for ODBC database access, the Microsoft Open DataBase Connectivity standard based on the SQL database model.
Whilst a newcomer to databases would probably be happy to settle for plain 2-dimensional data access, for the programmer who has been used to the flexible 3-dimensional (multi-valued), dynamic model offered by Pick it’s a bit of a come-down. To summarise, with ODBC you won't get:
In other words, although you'll be able to deploy your application using lots of different databases, you will not have the rich set of database development features which you've had for years under Pick. I've lost count of the number of people who've said to me ‘You know what - it’s only when you move away from Pick and then return back to it a few months later that you really appreciate what you've been taking for granted for years.’
ODBC is not, as some may have you believe, a panacea for all database ills within Windows. It is a database API that is based on SQL. If you want to use ODBC you had better forget lots of the Pick niceties that you have been used to and get your head into SQL big-time.
Fine, you’re thinking, I've always fancied learning SQL. However, be under no illusions. Once you get past the relational database tag similarity it’s very different. You'll not only have to redevelop your programs, but you'll also have to redesign your whole approach to accessing and modifiying data.
Why? Well, the basic design strategy of SQL is that data relationships are defined partly in the data dictionary and partly by the way in which you access the data i.e. you need to know about the data structure in order to correctly format your enquiry statement. Pick's strategy is different. By using a powerful data dictionary approach, data interrelations can be defined once within the dictionary, thus shielding developers and end-users from the underlying data complexities. This approach in my opinion is one of Pick's great strengths.
Don't get me wrong, my name isn't Mr SQLbasher. SQL has some great features. The point I'm trying to make is that there is room for a bit of middle ground here. As a software developer with more years experience in Pick than I would wish to mention, I found the move into Windows application software development 2 or 3 years ago a frustrating experience. This led me to start the development of a piece of software that fits into that middle ground mentioned above.
What you need ideally is a piece of 'middleware' that presents you the application programmer with a database model that combines the best bits of both SQL and Pick and which can be deployed on either Pick or any ODBC-compliant database i.e. most SQL databases. It’s not sufficient to simply bolt on ODBC access into a Pick data-base; what we need to be presented with inside our application development language is an API that provides Pick-like data manipulation methods. This was the original design goal of TransBase.
TransBase presents a 3-dimensional database model to the Windows software developer that they can implement on either a Pick system or an ODBC database. It manifests itself as two separate pieces of software:
The way in which you access your data is via the familiar Pick item reads, writes, deletes, selects etc using multi and submulti values. However, if your back-end database server is SQL, the data is stored in a fully-normalised way, which means that any third party tools can still access your database in the usual 2-dimensional SQL manner.
To maximise programmer productivity, TransBase presents its functionality via objects - this both simplifies and improves the efficiency of database programming code.
David Cooper
Coyote Consultants
Last Updated: 30 June 1999