On Wed, Apr 23, 2008 at 9:23 AM, johnf <[EMAIL PROTECTED]> wrote: > On Wednesday 23 April 2008 08:00:47 am Nate Lowrie wrote: > > 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 > > But of course now you don't have a 1 to 1 you have a 1 to many, many, many.
How do you figure that? The relationship is from the customer table to the person table and it is 1 to 1 because a customer is 1 and only 1 person. A customer could be an employee but the relationship is still 1 to 1 for each table. > > Yes SQL is a tool that we again change designs for (depending on the SQL > engine). Postgres uses a sort of cursor to prevent dirty reads and MsSQL > does not. I have used both and they have caused me to change my table > designs. Right now Larry is working on a project that combines dbf's and > MsSQL which requires two different programs to deal with data. > > However, when you say Dabo has a way to deal with the situation then you > missed the point I was trying to make. What if Dabo was one of the object > database tools? Would you be required to even consider the relationships? > (BTW I have never used an object database - so I could be way off here.) No > the object would just be a customer. So adding information would just work. > To be honest I really don't understand how. But I have read a little about > it and the example is always the customer with all these 1 to 1 relations. Don't know. I have only ever used relational databases. Object db's suffer in performance compared to relational dbs and the problem domain is not well known or studied. I will say though that after using an O/R mapping layer on my projects code has becoming cleaner and simpler...Of course, that means decoupling the dabo biz layer from the UI but since all my forms on the project are a MVC architecture that is not much of an issue. > > My point is we change our designs, our programs to meet the needs of our > tools. I would go out on a limb and say that our tools limit our thinking. Just means we need a different tool or need to improve the existing one. You are absolutely right that tools limit our thinking because they put boundaries on the solution domain...However, I am going to say that a lack of tools is no substitute for poor design. Nate L. _______________________________________________ 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]
