Hm, I tend to make this as in place optimization, and a last resort.I like to have only a single set of mapping, for everything.
On Mon, Oct 13, 2008 at 5:45 PM, Fabio Maulo <[EMAIL PROTECTED]> wrote: > Separate DLL, for mappings, and use of NamedQuery is a best practice for > any ORM support it. > > 2008/10/13 N. D. <[EMAIL PROTECTED]> > > This is regarding NH or any ORM with such requirements (lets say EF + >> Oracle provider ) in general? >> >> >> On Mon, Oct 13, 2008 at 4:41 PM, Gustavo Ringel <[EMAIL PROTECTED] >> > wrote: >> >>> You should be able to move from NH to Oracle with little programming >>> cost. But for sure there will be optimization problems...so i will go for >>> distinct mappings DLL with optimizations of queries and ID Generators for >>> each DB...if you used named queries all the way...and intelligent id >>> strategies...switching the mappings DLL should be enough to maintain the >>> same app for Oracle / Sql Server. >>> >>> Same app one - to - one...is hell if it is not an easy app which can be >>> executed with a few standard and simple ANSI queries... >>> >>> Gustavo. >>> >>> >>> On Mon, Oct 13, 2008 at 4:32 PM, Ian Joyce <[EMAIL PROTECTED]> wrote: >>> >>>> >>>> I've had to go from MySQL to MSSQL. Luckily I was using Hibernate >>>> which made the switch painless. >>>> >>>> --Ian >>>> >>>> On Mon, Oct 13, 2008 at 9:04 AM, Ken Egozi <[EMAIL PROTECTED]> wrote: >>>> > I really don't get the need to swap RDBMSs. >>>> > I mean, really. how many times in a lifecycle of a majot application >>>> does >>>> > one switches his high-cost Oracle servers into the >>>> > not-as-high-but-still-high-cost MS-Sql? or from Postgres to MySql >>>> > whaterver? usually it'd be a kind of a strategical desicion that will >>>> be >>>> > accompanies by business changes -> thus a change to the app anyway. >>>> > >>>> > Especially doesn't make sense in switching Oracle/SqlServer. Both are >>>> pricey >>>> > (one of them rediciulusly pricey), and you'd spent the dimes if you >>>> want to >>>> > squeeze some special things that only this said server can give you. >>>> So you >>>> > end up with special PL-SQL/T-SQL code that needs to be migrated >>>> anyway. >>>> > >>>> > My stance is that if you didn't get to the point of needed the >>>> propriety >>>> > stuff in the DBMS, then you don't have any reason to switch DBMS >>>> anyway, cuz >>>> > you won't use the propriety stuff in the target system anyway. and if >>>> you >>>> > will, then it's a change in the application anyway, so why bother with >>>> > "switchability" to begin with? >>>> > >>>> > >>>> > End Rant >>>> > >>>> > >>>> > >>>> > >>>> > unless you write a simple application that will get installed on many >>>> > places, and even then for low-needed scenarios I'd go with an embedded >>>> > Firebird / SQLite or SQL Express installation, while for large >>>> > >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -- > Fabio Maulo > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
