Hi Ray, > In lieu of further workload > increase by one more hasty submission of possibly immature feature or > enhancement request, it might be prudent to conduct a more thorough > deliberation in the forum before the community collectively decides > that the intended subject would be a worthwhile effort. We can then > move this subject through IssueZilla. Hopefully this approach will > increase the value of requests submitted through IssueZilla that your > team has to distill into the next version of specifications.
Well, I consider every request for a change, as long as it doesn't decribe something which is already available, a valid one. That is, if the RFE requests a feature which isn't there, it's a valid request. If it requests another approach to an existing feature (e.g. for better usability), it's a valid request. This doesn't say anything about when this will actually be implemented - in fact, we have more RFEs than we will address in the next <number_of_your_choice> years. However, having the wishes of the users filed is a good thing, IMO ... Anyway, you're of course also welcome to let the idea mature in mutual discussion :) > field 03 | field 07 > (number) | (text) > -------------------- > 1 | name 04 > 1 | name 04 > 2 | name 07 > > [flawed data] Well, you maybe could call this flawed data. But in reality, it will happen. In all cases I can imagine I could probably also argue that the design of the data is still broken, and could be repaired by, say, adding a time stamp to a row. Nonetheless, it will happen that people have exactly this kind of "duplicate" data. Speaking strictly, it's not even flawed data. At least the backend - the place where the concrete record data is written to some file - can distinguish those records, at least by relative position in the file. Now if the backend would expose the possibility for distinction to its clients, all would be fine. (Which btw. leads us to the potential driver capability of bookmarks: driver/backend-dependent unique row values, which are not interpreted by the clients, only used for identifying records when talking to the database.) > field 03 | field 07 | field 09 > (number) | (text) | (number) > ------------------------------ > 1 | name 04 | 17 > 1 | name 04 | 23 > 2 | name 07 | 23 > > When all three fields are present, every record is unique. If one > looks at only two fields as one might in a SQL Select result, we > return to the previous scenario of APPARENT duplication in PARTIAL > information. In other words, the perceived problem of duplication > does not exist. No one would expect in logical mind to change > (insert, update, etc.) the data without specifying the other fields. > Or at least I expect data analysts to know their data. Or at least we > should realize that a specific vehicle cannot be distinguished by > color alone (too few attributes). But even then, how to execute a user request such as set "field 07" to "name 08" in the row where "field 03" is "1" and "field 09" is "23" ? Though the composed view does contain only unique records, the constituting tables don't. Updates cannot include the fields from the first table - which does not have "unique" records -, but only fields from the second table. So there's effectively no difference to only updating the second one. > 3. Can someone invite an experienced database designer, > not software developer, to help on this discussion? Which you did by asking - some experienced database designers are reading here, /me thinks, and I hope they join ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
