On 9/15/05, Nick Han <[EMAIL PROTECTED]> wrote: > Barney, can you reduce the language down like a fraction so I can > understand better on what you just said?
I'll take a stab at it. Sometimes there's a one-to-one relationship between the tables in your database and the classes in your code. For example, say you have customers and orders. A customer has an customer number and a name. An order has a customer number, a date, and a list of items. In your relational database, you'll probably have a Customers table with two fields: customerNumber and name. In your object model, you'll probably have a class called Customer with two attributes: customerNumber and name. There's a one-to-one relationship between your object model and your relational model. You might have a CustomerDAO to perform the incredibly simple job of mapping Customer objects to rows in your Customers table. For orders, you might have a class called Order. Order has attributes customerNumber, date, and items. Items is in array of structs, with keys "name" and "quantity." In your database, you could have an Orders table with orderID, customerNumber, and date. You also have an OrderItems table with orderID, itemID, and quantity. And there's an Items table with itemID and name. In this case, you have one class (Order) and three tables (Orders, OrderItems, and Items). There's definitely not a one-to-one relationship between the object model (classes) and relational model (tables). Because you want to abstract away the database as much as possible, you store and retrieve Order objects with an OrderDAO. OrderDAO has to go to three different tables in the database. That may be okay with you. If you'd rather have each class talk to only one table you can introduce what folks on this list call Data Gateways. You would have one class for each table: OrdersDG, OrderItemsDG, and ItemsDG. OrderDAO wouldn't have any SQL code. Instead it would talk to OrdersDG, OrderItemsDG, and ItemsDG to store and retrieve information from each of their respective tables. Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.weblogs.us ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
