BTW, that article is OO design concepts in Database design not about a database that allows inheritance and object creation as concepts inherent in the database.
At 14:31 16/01/2002 +0000, you wrote: >Hey folks. > >I've used postgres' Object Relational features a few times, but it only really >makes sense if you have lots of data and you have code that helps transfer >your objects directly in the system in context. By that I mean, that it's not >worth the effort if you deal with your data in a linear fashion in a >website say. > >This is a very good book on the subject, >http://vig.prenhall.com/catalog/academic/product/1,4096,0131238299.html,00.html > >and http://www.devx.com/premier/mgznarch/vbpj/2000/04apr00/dd0400/dd0400.asp >is a good article on the subject/concepts. > >If you (or anyone) wants some more info just mail me. > >Max >p.s. postgres is a very rocking product, out of DB2, Oracle, Sybase ASE, >SQL server and postgres for your money it's phenomenal. It's got some >annoying idiosyncrasies like no owner.database.table.col access to various >databases. Anyway, now I'm just rambling. > >At 08:13 16/01/2002 -0600, you wrote: > >/charlie > > > >I believe postgres in an Object Oriented Database. I've seen various desgin > >tools (Sybase's powerdesigner) that allow you to make certain tables inherit > >properties of other tables. All in all I have to say I could see where OO > >design in Database would come in handy but I haven't had enough practical > >exposure to know how to proceed. > > > >Leon > > > > > >-----Original Message----- > >From: charlie arehart [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, January 15, 2002 11:27 PM > >To: SQL > >Subject: RE: Database configuration ? > > > > > >Dina, I notice you refer to them as "business objects". Was your recent > >study come more of an object-oriented design approach? I only ask that > >because it's dawned on me as I study OO design that a lot of concepts seem > >to be easily translated (as you note) to database design. > > > >Just as you don't want a class in oo design to have any data not related to > >a given entity, we also don't want a table to reflect more than it needs to. > >And just as we don't want to have redundant data in a table (choosing to > >normalize it, like you say), that's similar to the idea of moving some data > >out of instance variables and into class variables. > > > >Anyone else given thought to this? Or is it a bit to esoteric for a SQL > >list? :-) > > > >/charlie > > > >-----Original Message----- > >From: Dina Hess [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, January 15, 2002 11:12 PM > >To: SQL > >Subject: Re: Database configuration ? > > > > > >hi doug, > > > >i just finished studying that stuff not too long ago...and you've got > >the right idea. you first examine the business objects you'll be using. > >since you'll be selling a product, you'll have orders. each order will > >have one customer, but a customer can have many orders. each order can > >include many items (products)and an item can be associated with many > >orders. since you want to create one-to-many relationships in your > >database, you'll need to create an association table for business > >objects with many-to-many relationships, like orders and items. remember > >the primary key of the 'one' side of the one-to-many relationship goes > >into the table on the 'many' side of the relationship as a foreign key. > >the association table you create to handle many-to-many relationships > >will combine the primary keys of each of the 'many' tables to form its > >own primary key. this synopsis scratches the surface of an important > >relational database concept known as 'normalization' in case you want to > >dig further. > > > >hth, > >dina > > > > ----- Original Message ----- > > From: charlie arehart > > To: SQL > > Sent: Tuesday, January 15, 2002 8:48 PM > > Subject: RE: Database configuration ? > > > > > > Jeffry offers a succinct and useful response. Frankly, the nature of > >the > > question suggests that you'd be really well-served by doing a little > >reading > > on relational database design. Then this sort of question becomes old > >hat. > > :-) > > > > There are many excellent titles. Just do a search on "database design" > >at > > amazon and look at its most popular choices. Most are uniformly good > > (because the concepts are fundamentals which all DB designers should > >know). > > Some definitely take a lighter approach and are very approachable (and > >not > > going to be boring.) > > > > It's always tempting to jump right in, or lean on folks to help, but > >this is > > stuff you'll constantly bang your head against until you learn those > > fundamentals. You'll also save yourself a LOT of headache by designing > > things right up front. It's a nightmare to change things later (both > >the DB > > design and the code). > > > > /charlie > > > > -----Original Message----- > > From: Jeffry Houser [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, January 15, 2002 7:04 PM > > To: SQL > > Subject: Re: Database configuration ? > > > > > > : hmm: > > > > Well, there are way too many variations to tell you specifically > >what to > > do, but... > > > > I would do something like this: > > > > Artist (ArtistID, Artistinfo) > > Song (SongID, SongInfo) > > Disc (DiscID, DiscInfo) > > > > DiscSongArtist (DiscID, SongID, ArtistID) ( This is an > >intersection > > table and will give you the songs on a disc and the relevant > >artist.... for > > example, both Madonna and Don McClean do a version of American Pie.. > >you > > will want your system to be able to handle that without problems. > >Also it > > is not uncommon for a single song to be on multiple CDs, for example > > anything that was released as a single is usually on a full length > >album > > and the single ) > > > > > > As far as ordering stuff, yes I would separate price into it's own > > table. Are the prices going to change on a routine basis? If so, > >then > > when an order is created, I would also store the current price of the > >item > > in the order tables, as every time a price changes you aren't changing > >past > > orders in the process. > > > > I am wondering what site you are working on. > > > > > > > > At 02:28 PM 01/15/2002 -0800, you wrote: > > >I am trying to figure out how I should set up a database for an > >ecommerce > > >site. I will be selling music CD's. > > > > > >Each artist can have several albums, and each album can have several > > >tracks. I am pretty sure I will need 3 tables for that info. What I > >am > > >wondering , is where should I keep pricing info and such? Should it > >be in > > >the album table or should there be a seperate table for pricing etc. > >Any > > >insight would be helpful. > > > > > > > > > > > >There are two major products that come out of Berkeley: LSD and > >[Unix] > > >BSD. We don't believe this to be a coincidence. > > > > > > > > > > > >Doug Brown > > > > > >Archives: http://www.mail-archive.com/[email protected]/ > > >Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebarsts > > > > -- > > Jeffry Houser | mailto:[EMAIL PROTECTED] > > AIM: Reboog711 | ICQ: 5246969 | Fax / Phone: 860-223-7946 > > -- > > DotComIt: Database Driven Web Data > > My Book: Instant ColdFusion 5 | http://www.instantcoldfusion.com > > My New Book: ColdFusion: A Beginner's Guide February 2002 > > -- > > Far Cry Fly, Alternative Folk Rock > > http://www.farcryfly.com | http://www.mp3.com/FarCryFly > > > > > > > > > > > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
