[SQL] surrogate keys and replication.
Josh, I agree to treat this case as a (1) convinence. But it is still very cpecific, more than just simplifying FKs And you have said about general GUID problem. Let we disscuss this problem ? I hope to here good ideas from you again. Now I solve the GUID problem, with one sequence of IDs on the main server. The clients ask the server to lease some IDs via special (application-layer) protocol. Server remembers who and when and what IDs have took. (in terms of segments [a..b],[c..d]... etc) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] surrogate key or not?
On Tuesday 27 July 2004 02:04 am, Karsten Hilbert wrote: > One thing we ARE looking for in our records is the ability to > find groups of patients by arbitrary criteria since one day > I'll have to find all my patients whose father took a statine, > whose second-born child suffered a bout of neutropenia 2 weeks > after birth and who started being on the pill at age 14. > Because they'll have a 3fold increased risk of lung embolus. > Unless monitored for clotting factors every 6 months. Which I > will have to do from now on. Get my point ? :-) couldnt you do something like, let them write the 'long flaky text', and at the same time mark a certain number of key words or key phrases which could be stored and retrieved? -- regards kg http://www.onlineindianhotels.net - hotel bookings reservations in over 4600 hotels in India http://www.ootygolfclub.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] surrogate key or not?
Ð ÐÑÐ, 23.07.2004, Ð 09:57, Kenneth Gonsalves ÐÐÑÐÑ: > also, how did you get that neatly formatted output of the schema? This is postgresql_autodoc: http://www.rbt.ca/autodoc/ -- Markus Bertheau <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] surrogate key or not?
> > One thing we ARE looking for in our records is the ability to > > find groups of patients by arbitrary criteria since one day > > I'll have to find all my patients whose father took a statine, > > whose second-born child suffered a bout of neutropenia 2 weeks > > after birth and who started being on the pill at age 14. > > Because they'll have a 3fold increased risk of lung embolus. > > Unless monitored for clotting factors every 6 months. Which I > > will have to do from now on. Get my point ? :-) > > couldnt you do something like, let them write the 'long flaky text', and at > the same time mark a certain number of key words or key phrases which could > be stored and retrieved? I was thinking along similar lines. On one hand, you need the "long flaky text" (love that expression), on the other, you want to ensure that you can locate appropriate data, and that the required details are available. By available, I mean that it was entered in the first place, and that it is retrievable. I imagine a system whereby you define keywords and attributes for them (attributes would be an episode date, or dosage, etc). The memo, is checked for keywords and the doctor prompted to supply the attributes for them. If your parsing was smart, and the memo formated a little, you could conceivably pull a lot of this out of the memo as defaults. The processing could also be done retrospectively by an intern or researcher, but I imagine it would be best to have the doctor do it at the time. Just some vague ideas anyway. This may of course be much more work than anyone wants to get into... I don't have much experience with text searching systems, but something reasonably sophisticated would probably get you there. Regards Iain ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] surrogate key or not?
On Wednesday 28 July 2004 06:59 am, Iain wrote: > > couldnt you do something like, let them write the 'long flaky text', and > > at > > > the same time mark a certain number of key words or key phrases which > > could > > > be stored and retrieved? > > I was thinking along similar lines. On one hand, you need the "long flaky > text" (love that expression), on the other, you want to ensure that you can > locate appropriate data, and that the required details are available. By > available, I mean that it was entered in the first place, and that it is > retrievable. I imagine a system whereby you define keywords and attributes > for them (attributes would be an episode date, or dosage, etc). The memo, > is checked for keywords and the doctor prompted to supply the attributes > for them. If your parsing was smart, and the memo formated a little, you > could conceivably pull a lot of this out of the memo as defaults. The > processing could also be done retrospectively by an intern or researcher, > but I imagine it would be best to have the doctor do it at the time. simpler, as a first stage and easily implemented, give him some way he can tag words and phrases he feels important. save these in a table along with a foreign key identifying the source. as a second stage keep analysing the words and phrases chosen and empirically build up a database of significant words and phrases relevant to that specific installation (or doctor), and as a third stage, highlight these as he types in the data -- regards kg http://www.onlineindianhotels.net - hotel bookings reservations in over 4600 hotels in India http://www.ootygolfclub.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
