It's interesting that this is yet another issue of where exactly you
want to place your business logic. Do you do it as much as you can on
your sql server or do you bias it towards your client application. It's
obvious that you can do cross database linking in your application
layer, but if you want to keep your logic on your server as much as
possible, you need some form of cross database linking at the server
level. It's sort of a matter of taste, but there are lots of people who
like to keep there logic on the server or at least within sql
statements, so there's probably a good sized market that your not
reaching if you ignore it.
Tony Caduto wrote:
> Ron Johnson wrote:
>>> be separate databases because they're clearly related data.
>>>
>>
>> Just because they are related, doesn't mean that it's always wise to
>> lump it all in the same database. Mainly for scalability and
>> performance reasons.
>>
>>
> I would tend to agree, there are numerous times being able to do a
> cross database query without the hassle of DBlink
> would be extremely handy. I could also see it being valuable in a
> data warehouse type situation.
>
> I know it can be done in M$ SQL server using .. notation and I bet you
> can do it in DB2 and Oracle.
> you can even do it in MySQL, in MySQL it's their way of implementing
> schemas.
>
> Considering all these other DBs can do it, doesn't it make sense to at
> least put it on the radar for Postgresql?
>
> Just my 2 cents....
>
