Thread: Re: [GENERAL] temporary tables
hi, I commonly use COPY to import txt files to pg tables. You can use a simple statement as : insert into permanent_table select * from template_table ; This will append the new rows to the existing ones in the permanent table. hope that helps Omid Omoomi >From: "sheila bel" <sheilabel@hotmail.com> >To: pgsql-general@postgreSQL.org >Subject: [GENERAL] temporary tables >Date: Wed, 16 Feb 2000 15:42:21 GMT > >Hi everyone, > >I'm trying to create a temporary table, store some data >in it then after a while copy the data into another table >and drop the temporary. I'm not sure exactly how this is >done. I went to Mr. Momjian's Manual before posting this >question and found the title of temporary tables at: >http://www.postgresql.org/docs/aw_pgsql_book/node148.html >but I was disappointed to find nothing in there. >Reminded me of when I was looking for info about primary >keys. > >For copying data from one table to another I did check >out the COPY command of SQL commands but there wasn't a >clear example to show how it is exactly done from one >table to another. I'm sorry if my question is so basic, >I'm just finding it difficult to find information >specially without a book. > >The data that needs to be copied is either text or password. >This is what I think should be done please correct me if >its wrong : >COPY temptable(attributes) To permanent_table(attributes); > >If someone could give me an example I would really appreciate >it. > >-Sheila >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > > >************ > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
I'm trying to build what amounts to an appointment book for a doctor's office. The office has multiple doctors, and my application is going to handle patient appointment scheduling for all the doctors(among many other things). Anyway, I am looking for advice on database table design. I'll be tracking the date and time of the appointment, the doctor, reason for the appointment, insurance company authorization and the patient's name. I'll also need to be able to view open appointment blocks, and I would like as much flexibility as possible in setting the times of appointments. If anyone has any suggestions or advice regarding table design, I would really appreciate it. I'm not sure at all where to start. With things like open appointments, this seems much more complex than the typical name, address, phone number databases I've done in the past. Thank you for any help. David Barnes
Barnes wrote: > > I'm trying to build what amounts to an appointment book for a doctor's > office. ... > > If anyone has any suggestions or advice regarding table design, I would > really appreciate it. I'm not sure at all where to start. With things like > open appointments, this seems much more complex than the typical name, > address, phone number databases I've done in the past. A short answer to a rather complex question... You might consider looking into "Entity-Relationship Modelling". You can read about E-R modelling in almost any relational database book; it is the heart of relational database design. Other helpful processes for ER-modelling include user-interface prototypes and "Use-Case Scenarios", also available in software design texts. Another related crucially important process is "normalization". It is also readily described in cryptic academe-speak in the same RDBMS texts, but if you're fortunate, you can find an author able to translate into understandable english:). Normalization is essentially a process that helps you avoid some painful chronic ER-Modelling mistakes. ER-modelling can be quite tedious, but has a huge and lasting payoff during development and evolution if done well. Cheers, Ed Loehr
On Wed, 23 Feb 2000, Ed Loehr wrote: > Barnes wrote: > > > > I'm trying to build what amounts to an appointment book for a doctor's > > office. ... > > so, it is used by office secretary, not patient directly? why not? I'm curious.
Yes, it is a tool for the support staff to handle scheduling. I would be very reluctant to allow patients to use an appointment scheduling tool for a doctor. People who aren't trained tend to do unpredictable things, whether intentionally or accidently, and while I won't rule out the ability to someday see openings in the schedule and insert an appointment from the Internet, I think the potential risks are high. Someone with an ill founded sense of humor might decide to fill in a hundred appointments for Mickey Mouse, which would be expensive. What do you think? David Barnes aardvark@ibm.net -----Original Message----- From: kaiq@realtyideas.com [mailto:kaiq@realtyideas.com] Sent: Wednesday, February 23, 2000 2:30 PM To: Ed Loehr Cc: Barnes; pgsql-general@postgreSQL.org Subject: Re: [GENERAL] scheduling table design On Wed, 23 Feb 2000, Ed Loehr wrote: > Barnes wrote: > > > > I'm trying to build what amounts to an appointment book for a doctor's > > office. ... > > so, it is used by office secretary, not patient directly? why not? I'm curious.
it make sense. as an intermediate step, perhaps could be used for internal (doctor-doctor, nurse-doctor,...) "distributed" use, besides the "call-center-like" use. the table disign should be easy. scheduling itself can be just one or two (if support complicated feature) tables. So, just use your common sense (unless you really like it, no need for formal data modeling). A dirty way to do it (and this project is a very good one being dirty ;-) is put everything in one table! then, if you feel too filthy, consider split it into two (ok, that is modeling). You can ask help by showing the prototype design and your concerns. Also, there is some OSS schedular/time sheet there if you like to surf. Somebody (like me ;-) may have done the schedular but not authorized to publish them here. By put your prototype here, people can help freely. Some thing you really need to pay attention are: make sure use datetime and timespan datatype. do not use date or anthing else. also, be sure use serial type (or use a standard technique that do not use sequence or serial feature of the database -- so that the app can be portable among different dbms. But seems that it's not very often used and I do not really understand it. you can search the archive of this list. it's called hi-lo algorithm ;-) On Thu, 24 Feb 2000, Barnes wrote: > Yes, it is a tool for the support staff to handle scheduling. I would be > very reluctant to allow patients to use an appointment scheduling tool for a > doctor. People who aren't trained tend to do unpredictable things, whether > intentionally or accidently, and while I won't rule out the ability to > someday see openings in the schedule and insert an appointment from the > Internet, I think the potential risks are high. Someone with an ill founded > sense of humor might decide to fill in a hundred appointments for Mickey > Mouse, which would be expensive. > > What do you think? > > David Barnes > aardvark@ibm.net > > -----Original Message----- > From: kaiq@realtyideas.com [mailto:kaiq@realtyideas.com] > Sent: Wednesday, February 23, 2000 2:30 PM > To: Ed Loehr > Cc: Barnes; pgsql-general@postgreSQL.org > Subject: Re: [GENERAL] scheduling table design > > > > On Wed, 23 Feb 2000, Ed Loehr wrote: > > > Barnes wrote: > > > > > > I'm trying to build what amounts to an appointment book for a doctor's > > > office. ... > > > > so, it is used by office secretary, not patient directly? why not? > I'm curious. > > > >