On Wed, Apr 23, 2008 at 8:34 AM, johnf <[EMAIL PROTECTED]> wrote: > > On Wednesday 23 April 2008 06:49:10 am Nate Lowrie wrote: > > On Wed, Apr 23, 2008 at 7:38 AM, Ed Leafe <[EMAIL PROTECTED]> wrote: > > > On Apr 23, 2008, at 8:31 AM, johnf wrote: > > > > I normally don't have two tables for a 1 to 1 relationship. Most > > > > database > > > > engines today allow plenty of fields and hard drive space is very > > > > cheap these > > > > days. > > > > > > That is never an excuse for poor design. I'm assuming that > > > Karsten's design is correct for his application; you should never have to > > > change a good design to work with your application tools. > > > > Agreed. Plus, if you do an O/R layer it makes things a real pain in the > > butt... > > What's a real pain in the butt? > > We change database designs all the time to meet the limits of our tools. Not > that we should just blindly accept the limits of tools. And Dabo is no > exception. And yes we change the way we might design something to meet the > needs of Dabo. When Larry designed a 1 to 1 relationship on one our the > forms Ed immediately suggested to convert it to one table (about a year ago). > Why because we were having trouble with Dabo. Ed did not suggest that the > design was wrong only that Dabo didn't work as expected. Don't know or > recall if that problem was fixed or not. But that's not the point. Ed > suggested a practical solution. > > Nate, tell me why you decided to use two tables instead of one? Has Dabo's > limits caused you to re-think the two table solutions. I.e. Dabo can not > update multi tables from datasets created from joins. And I guess there > aren't many tools that can. My point is it is often better to change the > design than fight the tools. And again Dabo is no exception.
For those chiming in, this discussion is about the customers and persons tables from yesterday's discussion. What I didn't mention (as it wasn't relevant to the question) was that I have to store employees and supplier contacts as well. The customers table was originally one table, but I refactored all of the data that belonged to a generic person out into it's own table. Employees and Persons enjoy that same relationship as well. On the object side of things, I am now able to refactor the customer object, pull out the person info and the customer and employee objects subclass the new person object. Both make sense, and refactoring the database directly helps with the O/R mapping. Dabo's limits are not the problem. Not even really an issue, as you just need a third lookup bizobj that joins the 2 tables for lookups and searches. The limitation is not in the tools. Dabo might not be able to do CRUD operations on the 2 tables with a single bizobj, but you can certainly do it quite easily with 2 bizobjs and a couple lines of code in the db access layer... So, I am not saying that one table is wrong. It satisfied me up until the point that I needed to add more functionality and then I refactored to a better design. I am not really even fighting dabo. If anything, I am fighting SQL and I can't change that...But, still as long as you can accomplish what you need with your tools in a reasonable manner, is there any reason not to refactor the db design to be better? _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
