> In theory joining cross databases is not supported in the SQL > standard. Therefore not every dbms will implement it, or they > will require you to use clumsy workarounds.
I assume this goes for cross-server queries as well (such as linked servers in SQL Server)? > I find it hard to see the advantages when you can also use > namespaces (schema's) for logical separation and tablespaces for > physical separation (other diskdrive). Unless your database is > *really* big, but then replication/clustering might be a better > solution. Well, sometimes it's just a heck of a lot easier. For instance, I'm working on several apps that either deal with data migration or collaborative creation. The SAP system (running either Oracle or SQL Server) is set up as a linked server or, sometimes, is just another database on the same server. Views are then built in the application database that query the SAP system (read only of course) to build lists of vendors, customers, etc. Now, we could import the data nightly into the application database. In fact, these apps can work that way if necessary. However, they import the data into its own database (as opposed to a name space). The reason this is done is because the data, which is usually many gigs in size, doesn't need to be backed up. The application database, which is relatively small, is backed up using standard database maintenance plans. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net http://www.cfhosting.net Message: http://www.houseoffusion.com/lists.cfm/link=i:4:184985 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
