Help with a Architecture for Multi Database Application

Posts   
 
    
eugenio
User
Posts: 2
Joined: 27-Aug-2008
# Posted on: 27-Aug-2008 14:22:04   

What i need to do to configure my application to use multi database, like SQL Server and Oracle?

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 28-Aug-2008 08:49:43   

Is your structure the same in the two DBs (SqlServer and Oracle)? Or... Do you have different business domains (SS = Sales database, Oracle = Messaging database, for example)?

David Elizondo | LLBLGen Support Team
eugenio
User
Posts: 2
Joined: 27-Aug-2008
# Posted on: 03-Sep-2008 00:30:01   

Yes, i have the same structure in all databases.

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 12-Sep-2008 19:10:34   

You should use Adapter TemplateSet. This are the steps:

  1. Create a separate llblgen projects for each database type that you want to interface to.
  2. Change the ConnectionStringKeyName "Project property" for projects. For example "SQL.ConnectionString" and "Oracle.ConnectionString". This way DBSpecific projects could distinguish the connection string.
  3. Choose one of these llblgen projects as my "master" project.
  4. Generate the code out of both projects.
  5. Take both the DB Generic and DB Specific VS projects out of the llblgen "master" project. Take only the DB Specific VS project out of the other llblgen project.
  6. Now, put all together in a VS solution. You now have a solution with two DBScpecific projects and one DBGeneric one.

Persistence information is determined based on EntityName and EntityFieldName. You have to be sure the entity names and entity field names are the same in both projects.

David Elizondo | LLBLGen Support Team
Skeeterbug
User
Posts: 165
Joined: 21-May-2004
# Posted on: 23-Sep-2008 22:39:02   

Hey, The older version of our software had to run on Oracle, SQL Server, and DB2. We created an AdapterFactory that returned the correct DataAccessAdapter (configured via web.config). So the code looked like this:


using(AdapterFactory.GetDataAccessAdapter()) { ... }

We also dropped in a static string indicating which database was currently in use. Before that was added, we did conditional compilation symbols.


#if ORACLE
 // Code
#else
 // Other code
#endif

This was added because queries don't behave the same on each database. So in some cases we had to adjust the query differently for Oracle or vice versa. This became a nightmare and contradicts the entire idea of the AdapterFactory (you can switch the config, but it won't work right because of the compilation symbols might be wrong). Hence is why we added the static string.

So the example above became:


if(AdapterFactory.CurrentDB == "ORACLE")

In the last release I convinced my boss that it would be much more wise to only support SQL server because of our small team. If a customer demanded Oracle support, they pay extra for consulting fees (we host the solution now anyways, so this decision became easier). It is a maintenance nightmare, managing the different queries, managing update and install scripts between different database, making sure the DAL has generated the correct .NET types for all entities, etc. I am glad that chapter is finally over.

My advise is, don't support all the databases unless it is absolutely necessary. Imagine adding a column to your database. You must generate the update script for each platform. Then you must adjust any data. After that, you generate the new DAL, for each different platform. Every step you do you have to repeat multiple times, for each platform. Keep in mind each platform has it's own twist. Considering how often we change the database structure when coming out with a new version, this can easily add considerable time to the development cycle.

Thinking back on it, there are a few things our team could have done to make it more smooth. Even considering that, I still think it is a giant waste of time.

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 14-Oct-2008 09:59:08   

Skeeterbug wrote:

The older version of our software had to run on Oracle, SQL Server, and DB2

What LLBLGen version are you using?

David Elizondo | LLBLGen Support Team