Database Projects

[Joseph R. Justice]

[Intentionally sent to Miguel Tadeu because I didn't remember / notice
if he's subscribed to the list.  -- J]

On Wed, Jan 11, 2012 at 8:37 PM, Miguel Tadeu <mtadeunet at gmail.com> wrote:
> On Wednesday 11 January 2012 13:01:12 Milian Wolff wrote:
>> Miguel Tadeu, 10.01.2012:

>> >     - Language support for SQL
>>
>> define "SQL". MySQL? SQLite? PostgreSQL? ...? You'll need to concentrate on
>> one "dialect" first and then might work on others later on. I agree that this
>> would be a nice thing btw.
>
> In deed, I would start with mysql first.

I'd like to comment that, if you plan from the start (and also
*implement* as well, e.g. not "just" plan) support for multiple SQL
server implementations / dialects, I think you'll be less likely to
have your support "locked-in" to some specific implementation's unique
features and idiosyncrasies, e.g. baked into the core of the support
where it'll be hard / disruptive to change it.  The benefit of this
would be that when you *do* try to add support for yet another new SQL
server implementation / dialect you'll hopefully *not* have to do a
lot of rearchitecting or refactoring of the existing code to
accommodate what the new SQL server does not have, has unique to it,
and/or has in a different implementation from what other servers have.

Of course, doing it this way will be more expensive to begin with,
since you'll have to take a lot more care in your initial architecting
and implementation of this support to factor out and/or make
configurable, plug-in-able, etc. things not common across multiple SQL
servers, or existing but different between them.  But, if you recall
the rule of thumb for software development that the later you get in
the life cycle of a software project or application to make a change
to that project, the more expensive the change is to make by a large
factor (multiplicatively or exponentially more expensive, even!), then
it might well be cheaper in the long run to do it this way, even tho
it is more expensive in terms of start-up costs.

I'd also like to comment that, even (and especially) for FOSS SQL
servers, there may be multiple active implementations or dialects of a
given server.  For example, for MySQL, I know there's the original /
mainline MySQL (currently owned by Oracle), and there's multiple
active forks of the original (such as MontyDB, and I'm sure many
others as well) which might not have everything the original has or
have things the original does not have and might not ever have.  For
PostgreSQL, there's at least the .org version and EnterpriseDB (tho I
think much code does flow from EnterpriseDB back into the .org
version).  I'm sure the same is true for the other major / active FOSS
SQL servers out there these days.  So, even here, it's not necessarily
as simple as saying "I would start with MySQL first".



I'd also like to comment that there are many "free as in beer" SQL
servers out there, that someone one day might wish to use with the
support you are proposing to add.  (And, of course, there's non-free
versions of these and other servers, as well.)  Off the top of my
head, I can think of Oracle, IBM DB2, and Microsoft SQL Server, that I
suspect have at least some sort of "free as in beer" version (as well
as for-pay versions), if only for personal / evaluation use.  Now, I
am not suggesting you "should" make sure that what you are doing will
work out of the box with these sorts of servers; I don't think that's
appropriate.  But, I *would* suggest that you consider how support for
these sorts of servers can be accommodated, if and when someone wants
to do the work to support them, with as little disruption at that
point in time to the work you are doing now.  Again, this returns to
the idea of planning from the start and implementing as well support
for multiple SQL servers and dialects.



Finally, I'd also like to comment that I'm aware of the various
"NoSQL" servers and dialects out there (many of them FOSS) which seem
to have a lot of buzz around them these days, tho I have the
impression that many of them might not have much in common beyond the
point of "not being SQL".  I realize that it's probably beyond the
scope of what you are suggesting to try to implement to add support
for (at least some of) these as well, not *least* of which is because
these things *do* seem to vary so widely, such that it'll be much
harder and more expensive to figure out how to accommodate all (or
even just a significant subset) of them.  Also, because they're so
much newer and actively developed (or even re-developed), they're much
more of a moving target than SQL servers are, where at least the core
is likely to be stable on an ongoing basis (and indeed where there are
in fact standards, even if the standards are insufficient for normal /
production use).  Finally, again because they're so much newer, it's
hard to know which (if any) of them is going to survive and flourish
over the long term, as opposed to being something that gets a lot of
buzz for a few years and then loses the interest of users.

Again, for all of these reasons, I realize it's probably beyond the
scope of what you are suggesting to try to implement to add support
for the various "NoSQL" servers, at least at this time.  However, I
think it might be good to keep in the back of your mind that these
things exist, and that at some point someone might want to implement
support for some (or all) of them as well.  Because, it seems to me
that it's at least possible that this hypothetical person might want
to use the work you are proposing to do now as a starting off point
for what *they* want to do, or that they might want to augment and
extend the work you want to do to accommodate these other types of
servers.  In which case, again, planning from the start and
implementing as well support for multiple SQL servers and dialects
might well make what they want to do later cheaper and less disruptive
to the existing code to implement (or even simply feasible to do
without whole-scale rewriting of the code).



Now, please note: I am *not* offering to assist with this effort, not
least of which because I am not set up to do any sort of serious
KDevelop development.  As such, I realize that what I've written above
is, essentially, "comments from the peanut gallery", and I fully
understand and expect that you will read these comments in that light.
 Even so, I hope you will give them at least a little consideration as
you plan out what you intend to do, and in what order you plan to do
it, in the hope that they will lead to a more effective use of your
time and efforts in the long run.

In any event.  Hope this is of some use, interest.  Thanks for your
time.  Be well.  And. good luck with what you are planning to do; I
look forward to reading more about it and hope it turns out well.

Joseph