<br><br><div class="gmail_quote">On Thu, Aug 20, 2009 at 3:46 AM, Maciej (Matchek) Blizinski <span dir="ltr"><<a href="mailto:maciej@opencsw.org">maciej@opencsw.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, Aug 19, 2009 at 10:13 PM, Philip Brown<<a href="mailto:phil@bolthole.com">phil@bolthole.com</a>> wrote:<br>
> On </div><div class="im"><br>
> but sounds like the earlier answer of "yes, you can join between two<br>
> 'separate' databases" will get you everythig you need, I think.<br>
<br>
</div>Data split into multiple databases will generally pose a problem for<br>
any non-custom system; '</blockquote><div><br><br>What we're doing IS custom.<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
if you look at any web framework (Rails,<br>
Django, CakePHP), it's usually expected that the complete information<br>
is contained within a single database.</blockquote><div><br>But if it cant work by passing in DB.table references, instead of pure [table] references, it's THAT system that is broken. Go fix THEIR code, or find a better framework?<br>
<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It's especially important in<br>
places where the database access layer is decoupled from the model; if<br>
at some level the application doesn't know the specifics of the<br>
database, it can't expect to know that there are two or more of them,<br>
and which class is stored in which database.</blockquote><div><br>It doesnt have to "know" anything. It just has to transparently pass in references.<br>And as I said, if it cant accept DB.table references in place of table references, it's THEIR code that is broken.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Using multiple<br>
databases is database-engine-specific (you can't do cross-db joins in,<br>
say, Berkeley db, can you?), </blockquote><div><br>berkeleydb isnt a "real" database, so that's a bad comparison.<br><br>you CAN do it in oracle, fyi.<br>So, we have<br>- ok in oracle<br>- ok in mysql<br><br>
<br>(Although what mysql calls a "database", oracle calls a "schema". but the syntax is identical)<br><br>Any "database framework" that cannot support a fundamental, basic operation supported by both mysql, and oracle, is broken.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Is there a technical reason for a separate database for package<br>
information? It looks to me as if the tables from the CSW database<br>
could be moved to the MANTIS one.</blockquote><div><br>Certainly. Proper data abstraction.<br>The mantis database is a "data object", if you will.<br>Violating object cohesion is bad programming.<br><br>PS: even "sqlite" supports "cross-database joins". See their faq.<br>
<br><br><br><br></div></div>