Re: light weight, stand alone data solution
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Fri, 30 Oct 2009 11:50:26 -0500
It was a silly response to a reasonable answer. The answer was "call subroutines", which
seemed obvious. But then the response was "but this will prevent my plugging a real
database in". It seemed screamingly obvious that to minimize future rewrites, the
solution would be to create a subroutine that provided the necessary abstractions. Instead
of issuing a SQL request, just call the necessary subroutines to interface to the
database.
I did database programming from 1984 through 1997, and stopped when the database
technology got too expensive to use (SQL, Oracle). I have barely touched it since.
I've done this several times to abstract database access from database implementation, and
in one case we just replugged SQL commands in a few years later. I didn't do it, but the
client said that it took only a couple days to make the conversion, because we had planned
on this when the code was written. So it is possible, and it wasn't even very hard. We
once converted a dBASE interface to a Paradox interface in a couple days, maintaining
common source depending on the customers' needs. If I'd had DLLs (this was in MS-DOS), I
would have simply created DLLs with the appropriate interfaces and we could have supplied
the DLL of choice to the customers (we did two different builds, instead).
The most recent one was an MS-DOS program converted to a Windows app, around 2000 or 2001.
What we did was write the SQL command as a comment (the client did this, I'm not a SQL
programmer), and I wrote a subroutine that implemented the SQL command by doing subroutine
calls. So when time came to update (which we anticipated) the entire body of the function
became a SQL call of the SQL command of the comment. I implemented an abstract notion of
"recordset" and the "get next record from recordset" call took a pointer to an object and
returned the data of the next record. Obviously this was trivial to change. I haven't
seen the current code, but mostly the change consisted of excising the clumsier code
required for the database library we were using (a dBASE IV-compatible library, and we
knew the database implementation was going to have a limited lifetime, which turned out to
be about five years).
So it is doable, and trivially, and it is obvious how to do it. Writing a subroutine is
not Rocket Science. The OP seemed to think that it was. I expect programmers to have a
minimum understanding of their profession, even if the complexities and subtleties of
particular APIs, MFC classes, VS idiosyncracies, etc. prompt detailed questions. The
response indicated a lack of this ability to reason about programming. I get tired of
people wanting solutions handed to them. Perhaps it is because I just taught a course in
which half the students were unable to do anything other than retype what I put on my
slides, and failed completely to reason about even the most elementary concepts of code
refactorization, abstraction, or generalization, that has left me disappointed with the
current state of programming education. (Simple example: I show an example with variable
names a, b, c; the students have typed in code that uses names x, y, and z, and then to
integrate the code from the slide, fail to see how the names in my code correspond to the
names in their code; instead, they use a, b and c and wonder why the names are undefined.
One even wrote variable declarations for them, then wondered why the (uninitialized)
variables didn't work!) I'm in the middle of converting a piece of code that would have
failed Introduction To C 101, and has taken days of effort just to rewrite to something
approximating Acceptable Practice (not even Best Practice; the client can't afford that!)
I'm tired of dealing with people who can't manage the obviously elementary skills of
programming. This is not Windows programming, it is not MFC programming, it is
really-basic-how-do-you-do-abstraction, something that everyone should understand how to
do.
joe
On Fri, 30 Oct 2009 09:37:30 -0500, "David Crow" <david_dot_crow@xxxxxxxxxx> wrote:
Different tactics, Joe? I've always admired your straight and nonsensicalJoseph M. Newcomer [MVP]
approach, but your response in this thread is borderline rude.
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:3fsle5tlbsr1fualmsql5ouscks7h72bak@xxxxxxxxxx
Duh. And exactly how will you plug in a "real database"? Hmmm...by
calling functions! Oh
wow, the complexity boggles the imagination...
Has it occured to you that you can encapsulate the abstractions in
subroutines? One
subroutine contains a sequence of SQLite calls, and next year it issues
SQL queries?
Or is the concept of abstraction too, well, abstract?
joe
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: light weight, stand alone data solution
- From: David Ching
- Re: light weight, stand alone data solution
- References:
- light weight, stand alone data solution
- From: BobF
- Re: light weight, stand alone data solution
- From: Goran
- Re: light weight, stand alone data solution
- From: BobF
- Re: light weight, stand alone data solution
- From: Joseph M . Newcomer
- Re: light weight, stand alone data solution
- From: David Crow
- light weight, stand alone data solution
- Prev by Date: Re: CMFCStatusBar pane text
- Next by Date: Vista - User Directory
- Previous by thread: Re: light weight, stand alone data solution
- Next by thread: Re: light weight, stand alone data solution
- Index(es):
Relevant Pages
|
