Re: [SQL] Table relationships
On Mon, 8 Jan 2007 17:07:56 -0600 Curtis Scheer <[EMAIL PROTECTED]> wrote: > -> Is there a difference between an address for the customer detail and an > address for the customer? > > Not really an address is an address, it's a matter of specify an address for > the customer master record which basically represents an entire customer > while the customerdetail represents departments within that company that > might be at a different address then the company's main office for instance. Could be that you need another table. Sounds like you have something like; company <===> address <===> detail Now you just have to indicate which address is the primary or head office. You can do that with a bool in the address table. You can even add a unique, partial index to address to assure that you only have one head office per company. Another alternative is to add another table which just holds the address: company <===> department <===> detail ^ ^ | | \==> address <==/ Obviously the address attached to the company is the head office. For departments you can either duplicate the reference to the address table or have NULL indicate a default to the head office. There are many possibilities. Which one is best will depend on analysing your particular business model. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Table relationships
On 1/9/07, D'Arcy J.M. Cain wrote: On Mon, 8 Jan 2007 17:07:56 -0600 Curtis Scheer <[EMAIL PROTECTED]> wrote: > -> Is there a difference between an address for the customer detail and an > address for the customer? > > Not really an address is an address, it's a matter of specify an address for > the customer master record which basically represents an entire customer > while the customerdetail represents departments within that company that > might be at a different address then the company's main office for instance. Could be that you need another table. Sounds like you have something like; company <===> address <===> detail This approach implies that the address defines the relationship between a company and the detail (the other departments/offices). I cannot think of a business model that would use this though there probably are some... Another alternative is to add another table which just holds the address: company <===> department <===> detail ^ ^ | | \==> address <==/ I'm not sure what this relationship is for. It would appear that a department can have different addresses for different companies. There are many possibilities. Which one is best will depend on analysing your particular business model. I agree whole heartedly. That is why I recommend starting with a logic structure before moving on to the physical. -- == Aaron Bono Aranya Software Technologies, Inc. http://www.aranya.com http://codeelixir.com ==
Re: [SQL] Table relationships
On Tue, 9 Jan 2007 09:13:35 -0600 "Aaron Bono" <[EMAIL PROTECTED]> wrote: > On 1/9/07, D'Arcy J.M. Cain wrote: > >company <===> address <===> detail > > This approach implies that the address defines the relationship between a > company and the detail (the other departments/offices). I cannot think of a > business model that would use this though there probably are some... Like the obvious one - companies have many places (departments) that things are shipped to and details are things that are shipped. > I'm not sure what this relationship is for. It would appear that a > department can have different addresses for different companies. Hmm. I guess I missed that. I'm just tossing out ideas here. Real, in depth analysis would require an invoicable relationship. :-) > There are many possibilities. Which one is best will depend on > > analysing your particular business model. > > I agree whole heartedly. That is why I recommend starting with a logic > structure before moving on to the physical. Absolutely. Don't even think about the tables until you have mapped out the business model. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[SQL] Question about GUI
Hello every body, I just want to know if there is some GUI with postgreSQL for Fedore Core 3?? Thanks in advanced!! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Question about GUI
Assuming you mean for administration, a couple of the options available out there are pgAdmin and phpPgAdmin... pgAdmin is a stand-alone program, available for both *nix and Windows, while phpPgAdmin is a web-based admin console. Another option is the PostgreSQL module of WebMin http://www.pgadmin.org/ http://phppgadmin.sourceforge.net/ http://www.webmin.com/ Personally, I use pgAdmin and have webmin with the Postgres module installed, although I don't use it. I haven't played with phpPgAdmin. Cheers, -p -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Judith Sent: Wednesday, 10 January 2007 10:45 To: pgsql-sql@postgresql.org Subject: [SQL] Question about GUI Hello every body, I just want to know if there is some GUI with postgreSQL for Fedore Core 3?? Thanks in advanced!! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ***Confidentiality and Privilege Notice*** The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments ---(end of broadcast)--- TIP 6: explain analyze is your friend
