>> what's your shortlist for the differences you're covering using your
environmental variable approach?
here ya go. Just a starter:
The goal is to have a set of CF functions/variables that mimicks the
various processing methods of each database engine, but abstracted so
the particular db implementation is hidden.
as I said, this is early days in doing this. I'd like to add MySQL5.0
into the mix as well (Oracle is a lost cause in our market share) but
we'll see how MSSQL + IDS goes first.
as usual, all comments/opinions/flames welcome.
cheers
barry.b
PS:
>> There are some instances where using stored procedures are the most effective
technique - why hinder SQL Server's performance if Informix doesn't support it?
so they're just as sluggish as each other!
Chris, I fully agree. the decision NOT to use SPROCs is not mine and I
wish it were otherwise. I'm only just been able to bring the standard
up to ANSI SQL-99 from ODBC SQL-82 - we now have REAL outer joins!
========================================
IDS vs SQLServer
length(entity_code) len(entity_code)
null::char cast(char, null)
- ltrim()
- rtrim()
- left()
- right()
|| + (concatenation operator)
decode(EXPR,1,3,9) (case EXPR when 1 then 3 … default 9)
substr(a, b, c) substr 3 args but its like
CF's mid() func.
a mod b a % b
today CURDATE( ), GETDATE( ) or DATE( )
select last serial value select @@identity
matches -
other stuff:
the fact that length function might have a different codomain
Union by itself IDS means: union unique yet to try SQLserver as
"union all" is also a possible default.
=======================================
On 4/28/05, Nando <[EMAIL PROTECTED]> wrote:
> Hmpft ... this is *exactly* what we need ... an omnipotent being on this
> list. :) Hell, even a semi-omnipotent being would be welcome.
>
> Barry, what's your shortlist for the differences you're covering using your
> environmental variable approach? Do you mind posting it and sharing how
> you're structuring this within the DAO's? Right or wrong, i think it's worth
> discussing.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Barry Beattie
> Sent: Thursday, April 28, 2005 4:00 AM
> To: [email protected]
> Subject: [CFCDev] multiple DAO's for different databases (was "While
> we're on the subject of DAOs")
>
> Chris Dempsey wrote:
> <quote>
> That said, in my meager experience, you tend to know ahead of time if
> this is required. Implementing the abstract DAO factory pattern is
> cool, but if you will only ever be on MySQL, its a bit of a waste of
> time. However, if you know you'll need to support XML, MySQL, Oracle,
> and SQL in the future, your code will be much more maintainable in
> separate DAOs.
>
> You can create a EmployeeOracleDAO.update(employee),
> EmployeeMySQLDAO.update(employee), EmployeeXMLDAO.update(employee),
> which take the same employee object and save it in different ways.
> </quote>
> =======================
>
> my problem with this is the
> EmployeeOracleDAO.update(employee) Vs
> EmployeeMySQLDAO.update(employee) Vs
> EmployeeMSSQLDAO.update(employee) etc
>
> and long term maintainance of these as seperate files.
>
> EG:
>
> We have the same code base but different customers will have different
> DB's. Before: Informix. Now: Informix OR SQLServer OR MySQL...
>
> we have lots of maintainance on existing code and our new DAO's won't
> be immune as bug fixes and enhancements will be added in the future.
>
> considering that 90% of our (mostly) ANSI -compliant SQL will work
> across all decient db's as is, and that we don't use T-SQL, PL/SQL
> extentions (hell, we can't even use sprocs thanks to Informix) we're
> just starting to add in-line conditions and environmental variables to
> cater for "select TOP 1..." Vs "select FIRST 1..." sort of things (the
> environmental variables for the client's DB are set up when the app
> first starts).
>
> I haven't yet come across a query that is so radically different that
> it needs to be spun out into it's own db-type DAO. While it's still
> early days on this project for supporting many db types, it just
> seems* more managable for future maintainance by NOT having multiple
> DAO files (XMLDAO excepted - it's totally different).
>
> any thoughts, opinions, etc?
>
> thanx
> barry.b
>
> (*I'm no omnipotent being - I'm throwing this out there to see if the
> ideas are "madness" or whether there's a legitimate "method" in
> there...feel free to flame - it's all learning...)
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
