Hi, Frank: Thank you for the detailed analysis. I have additional thought to share, as listed below, not necessarily following the original sequence in previous discussion.
1. enhancement request through OO IssueZilla Your OO Base team has been inundated by numerous comments and requests, as evidenced by the recent message volume at dba.openoffice.org and www.oooforum.org. 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. 2. data integrity My original question was much more primitive than the example illustrated in your discussion. In order to better dissect the concern raised in your discussion, let us examine the pure data in your contrived example, reproduced below. Ignore any DBMS issues (GUI, engine, SQL compliance, any thing) for now. field 03 | field 07 (number) | (text) -------------------- 1 | name 04 1 | name 04 2 | name 07 This set of contrived data contains an obvious duplication. Record duplication would not fit any database design since there is no way to uniquely retrieve the duplicate record. The reason is that no algorithm exists to distinguish identical records. Notice that the problem is at the level of data, not the software, be it DBMS (engine) or CUI (SQL dialect) or GUI (OO Base). There is flaw in the original data and the original data collection design. This is the responsibility of the data owner and user, not software. I shall discuss your desire to offer a solution at the GUI level later. In reality, this outright unintended duplication does not happen often because it would be caught early due to the severe consequence and the design would be repaired immediately. It is somewhat similar to software development that a crashing bug, albeit severe, is easier to identify and fix. Notice again that the repair effort is not necessarily carried out at GUI level. Now assume a properly designed database. No more flawed data or design. Every record can be uniquely identified and hence operated upon (insert, retrieve, revise, etc.). A more likely scenario involves views (in database parlance) where a subset of all available data fields are displayed according to selection rules (the SQL Select statements) involving additional fields not included in the displayed results. This is where GUI plays its major role. The views display only partial information, by choice of users, of the data. A contrived example is shown below, based on your previous example. 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). Notice once more that none of these issues are at GUI level. The APPARENT duplication exists only in the restricted view rendered by GUI. That was caused by intentional data selection, not by GUI. There is a last scenario. Instead of the previous flawed design prone to UNINTENDED duplication, one may design database on purpose like that. What type of utility of the design can be? I need more experience to become qualified to comment. At this point, an old political joke passed me: A politician has a great solution at hand. He or she is looking for a problem to apply. Now what was the problem? 3. Can someone invite an experienced database designer, not software developer, to help on this discussion? It is getting late. My mind is no longer as logical as in daytime. Please accept my apology if there is loophole in my previous discussion. Need to replenish my biological need now. Have a good day. Ray --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
