Hi Martijn, I got the point, but I wasn't talking about 1 application accessing both a public and private database. I was talking about a public application accessing the public database and an admin application that needs to access both. The menu bit I mentioned are equal in both databases, with the exception that one is used to render a public available menu from the public database and the admin menu is rendered from the admin database.
This way, I thought I could separate the public and admin even more. But as stated, it causes more problems then it solves. Regards, TJ. On Sun, Dec 28, 2008 at 10:18 AM, Martijn Korse <[email protected]> wrote: > > > Ralph Schindler-2 wrote: > > > > Right, as I mentioned, I might rethink the design of the two database > > system > > for your application. It might prove easier to put a column inside of > > your > > tables that would mark a row as 'admin' or not. > > > > I agree 100%. > Duplicating (part of) your database structure goes against every > normalization rule! An extra column would be the most obvious choice here. > > If you are worried that you might forget the filter in some queries and > thereby exposing admin-data, you could solve that by writing a clever > parent > class from which you extend all your other table-classes. If you give this > column (indicating whether the data belongs to the admin or not) always the > same name, you could write a mechanism in this parent class which checks if > the query is dealing with a table that has this column and then checks > whether an admin is logged in. If not, it adds another WHERE condition (if > not already present) that filters out the admin-data. > > ----- > http://devshed.excudo.net http://devshed.excudo.net > -- > View this message in context: > http://www.nabble.com/Using-2-databases-with-Zend_Db%2C-when-you-have-the-same-model.-tp21132662p21190945.html > Sent from the Zend Framework mailing list archive at Nabble.com. > >
