 | |
Designing a structure for a personal database
comp.databases comp.databases
 |
| | Thread Tools | Display Modes |
#71
 
| |||
| |||
|
Re: Designing a structure for a personal database -
05-08-2008
, 07:13 AM
|
On May 6, 4:22 pm, David Segall <da... (AT) address (DOT) invalid> wrote: Thanks Arved. I agree that the application probably reduces to a many-to-many relationship between persons and businesses in one table and locations in another and that does lead to the difficult and probably off-topic question of designing a GUI to represent that relationship. Not impossible to implement in a user-friendly way: on the edit form of one person the user sees the list of addresses and the "+" button, which leads to the address entry form. After the user clicks "OK" on the latter, the application checks whether the address already exists or not (even by applying some euristics, e.g.: "High St." is supposed == to "High Street"), and proposes to select among possibly equivalent addresses. New address is only added (and a record on the bridge table with it) if no existing one exists or none is selected by the user. |
for address. Nothing new - I believe GMail does it for addresses. Street
name is likely the most authoritative field; other fields are either not
selective enough (like unit number) or have different possibilities (like
municipality).
Something like what you suggest clearly has to be available for the general
case, or where autocomplete fails due to typos ("how the hell d'you spell
that anyway?").
[ SNIP ]
AHS
--
* change 'two' to '2' to email me
#72
| |||
| |||
|
|
On May 6, 4:22 pm, David Segall <da... (AT) address (DOT) invalid> wrote: Thanks Arved. I agree that the application probably reduces to a many-to-many relationship between persons and businesses in one table and locations in another and that does lead to the difficult and probably off-topic question of designing a GUI to represent that relationship. Not impossible to implement in a user-friendly way: on the edit form of one person the user sees the list of addresses and the "+" button, which leads to the address entry form. After the user clicks "OK" on the latter, the application checks whether the address already exists or not (even by applying some euristics, e.g.: "High St." is supposed == to "High Street"), and proposes to select among possibly equivalent addresses. New address is only added (and a record on the bridge table with it) if no existing one exists or none is selected by the user. |
for address. Nothing new - I believe GMail does it for addresses. Street
name is likely the most authoritative field; other fields are either not
selective enough (like unit number) or have different possibilities (like
municipality).
Something like what you suggest clearly has to be available for the general
case, or where autocomplete fails due to typos ("how the hell d'you spell
that anyway?").
[ SNIP ]
AHS
--
* change 'two' to '2' to email me
#73
| |||
| |||
|
|
On May 6, 4:22 pm, David Segall <da... (AT) address (DOT) invalid> wrote: Thanks Arved. I agree that the application probably reduces to a many-to-many relationship between persons and businesses in one table and locations in another and that does lead to the difficult and probably off-topic question of designing a GUI to represent that relationship. Not impossible to implement in a user-friendly way: on the edit form of one person the user sees the list of addresses and the "+" button, which leads to the address entry form. After the user clicks "OK" on the latter, the application checks whether the address already exists or not (even by applying some euristics, e.g.: "High St." is supposed == to "High Street"), and proposes to select among possibly equivalent addresses. New address is only added (and a record on the bridge table with it) if no existing one exists or none is selected by the user. |
for address. Nothing new - I believe GMail does it for addresses. Street
name is likely the most authoritative field; other fields are either not
selective enough (like unit number) or have different possibilities (like
municipality).
Something like what you suggest clearly has to be available for the general
case, or where autocomplete fails due to typos ("how the hell d'you spell
that anyway?").
[ SNIP ]
AHS
--
* change 'two' to '2' to email me
#74
| |||
| |||
|
|
It provides an excellent way of modeling real world data and the alternatives have not (yet) been seen as a serious challenge. |
lets you solve the problem as though you infinte RAM in a non-stop
computer.
see http://mindprod.com/jgloss/pod.html
You give up the ad hoc-queries.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
#75
| |||
| |||
|
|
It provides an excellent way of modeling real world data and the alternatives have not (yet) been seen as a serious challenge. |
lets you solve the problem as though you infinte RAM in a non-stop
computer.
see http://mindprod.com/jgloss/pod.html
You give up the ad hoc-queries.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
#76
| |||
| |||
|
|
It provides an excellent way of modeling real world data and the alternatives have not (yet) been seen as a serious challenge. |
lets you solve the problem as though you infinte RAM in a non-stop
computer.
see http://mindprod.com/jgloss/pod.html
You give up the ad hoc-queries.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
#77
| |||
| |||
|
|
David Segall wrote: We seem to have an irreconcilable disagreement that is based on different views of "true and correct". I think that chocolate cake is an important concept that we all share. You argue that real chocolate cake does not exist because nobody has produced a cake that is entirely chocolate and/or that there are zillions of different recipes for chocolate cake and/or that there are sound reasons for not eating chocolate cake. I can't refute any of those arguments. My view is that Straw man. That is not my argument; you have misstated my points irrevocably. the chocolate cake model is "true and correct" because everyone who reads the desert menu knows what chocolate cake should be and because chocolate cake has become an important part of the menu. You can eat two different chocolate cakes and feel that they don't even deserve the same name, they're so different. One can be white, the other brown. One can have icing, the other not. One can be very sweet and moist, the other rather dry and not so sweet. one can be made with tons of sugar, the other without any sugar at all. One might not even have chocolate in it, being made with carob and still billed as "chocolate" cake. I know, I've had them. We can never agree on this one. You see only the differences in the |
what makes a chocolate cake or a relational database makes me think
that both have a "truth" that exists outside any implementation.
Quote:
|
Once again, you cite an example that proves my point, despite your complete misstatement of my point. It seems that you agree that we have a common understanding of a "relational database" or the "Alto user interface" [sic] because you can that's the *Palo* Alto user interface. That's not even the name of the interface; it's simply where it was developed, at the *Palo* Alto Research Center in *Palo* Alto. I don't know how you came to think of that as the name for the interface principles. They were developed in Palo Alto, not "Alto". "Palo" is part of the name. Omitting the "Palo" is incorrect. The name of the city is "Palo Alto". Do not forget the "Palo". Palo Alto. http://en.wikipedia.org/wiki/Palo_Alto The interface was named after the Alto computer |
demonstrated. It was Xerox, not me, who chose to omit "Palo" from the
name. I prefer the term "Alto user interface" because it acknowledges
the origin but I agree that "graphical user interface" is much more
common and I will adopt it in future posts to avoid worrying the
reader.
#78
| |||
| |||
|
|
David Segall wrote: We seem to have an irreconcilable disagreement that is based on different views of "true and correct". I think that chocolate cake is an important concept that we all share. You argue that real chocolate cake does not exist because nobody has produced a cake that is entirely chocolate and/or that there are zillions of different recipes for chocolate cake and/or that there are sound reasons for not eating chocolate cake. I can't refute any of those arguments. My view is that Straw man. That is not my argument; you have misstated my points irrevocably. the chocolate cake model is "true and correct" because everyone who reads the desert menu knows what chocolate cake should be and because chocolate cake has become an important part of the menu. You can eat two different chocolate cakes and feel that they don't even deserve the same name, they're so different. One can be white, the other brown. One can have icing, the other not. One can be very sweet and moist, the other rather dry and not so sweet. one can be made with tons of sugar, the other without any sugar at all. One might not even have chocolate in it, being made with carob and still billed as "chocolate" cake. I know, I've had them. We can never agree on this one. You see only the differences in the |
what makes a chocolate cake or a relational database makes me think
that both have a "truth" that exists outside any implementation.
Quote:
|
Once again, you cite an example that proves my point, despite your complete misstatement of my point. It seems that you agree that we have a common understanding of a "relational database" or the "Alto user interface" [sic] because you can that's the *Palo* Alto user interface. That's not even the name of the interface; it's simply where it was developed, at the *Palo* Alto Research Center in *Palo* Alto. I don't know how you came to think of that as the name for the interface principles. They were developed in Palo Alto, not "Alto". "Palo" is part of the name. Omitting the "Palo" is incorrect. The name of the city is "Palo Alto". Do not forget the "Palo". Palo Alto. http://en.wikipedia.org/wiki/Palo_Alto The interface was named after the Alto computer |
demonstrated. It was Xerox, not me, who chose to omit "Palo" from the
name. I prefer the term "Alto user interface" because it acknowledges
the origin but I agree that "graphical user interface" is much more
common and I will adopt it in future posts to avoid worrying the
reader.
#79
| |||
| |||
|
|
David Segall wrote: We seem to have an irreconcilable disagreement that is based on different views of "true and correct". I think that chocolate cake is an important concept that we all share. You argue that real chocolate cake does not exist because nobody has produced a cake that is entirely chocolate and/or that there are zillions of different recipes for chocolate cake and/or that there are sound reasons for not eating chocolate cake. I can't refute any of those arguments. My view is that Straw man. That is not my argument; you have misstated my points irrevocably. the chocolate cake model is "true and correct" because everyone who reads the desert menu knows what chocolate cake should be and because chocolate cake has become an important part of the menu. You can eat two different chocolate cakes and feel that they don't even deserve the same name, they're so different. One can be white, the other brown. One can have icing, the other not. One can be very sweet and moist, the other rather dry and not so sweet. one can be made with tons of sugar, the other without any sugar at all. One might not even have chocolate in it, being made with carob and still billed as "chocolate" cake. I know, I've had them. We can never agree on this one. You see only the differences in the |
what makes a chocolate cake or a relational database makes me think
that both have a "truth" that exists outside any implementation.
Quote:
|
Once again, you cite an example that proves my point, despite your complete misstatement of my point. It seems that you agree that we have a common understanding of a "relational database" or the "Alto user interface" [sic] because you can that's the *Palo* Alto user interface. That's not even the name of the interface; it's simply where it was developed, at the *Palo* Alto Research Center in *Palo* Alto. I don't know how you came to think of that as the name for the interface principles. They were developed in Palo Alto, not "Alto". "Palo" is part of the name. Omitting the "Palo" is incorrect. The name of the city is "Palo Alto". Do not forget the "Palo". Palo Alto. http://en.wikipedia.org/wiki/Palo_Alto The interface was named after the Alto computer |
demonstrated. It was Xerox, not me, who chose to omit "Palo" from the
name. I prefer the term "Alto user interface" because it acknowledges
the origin but I agree that "graphical user interface" is much more
common and I will adopt it in future posts to avoid worrying the
reader.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.