Database Projects

[Miguel Tadeu]

On Friday 13 January 2012 15:31:49 Joseph R. Justice wrote:
> [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.
> 
Hi Joseph. Thanks for your reply. I'm thinking of making this plug-in driven, so several dialects can be supported.

> 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.
> 
Quite aware of this. This won't be a small project, so, several milestones and minor versions should be available to users in short development cycles, refactoring whenever possible and useful.


> 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'll start with MySQL open version. We'll see the how it hangs out with people and maybe some voluteers will want to develop some specific dialects, using some internal framework I'm planning to design. I'm only thinking on major database servers here, but smaller ones shouldn't be left out of the game.
> 
> 
> 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.
> 
Also several versions of each server will have to be considered. This will be a headache :)

> 
> 
> 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.
> 
I'd vote on waiting for good stable standards...Until then, I'll keep those out of scope

> 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).
> 
As long as it's scriptable, I don't see a problem on this.

> 
> 
> 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
> 

Thanx for the heads-up