Hi Ray, > I am not sure what your point is here. Normalization has been touted > by experts in R-DBMS designs to get us out of unnecessary troubles. A > normalized database design would not lead to this flawed data. There > is no need to deal with such a problem as it will not occur in a > normalized database. For non-normalized data set, one would of course > need a way to differentiate between duplicates which are bound to > happen. One asks for non-normalized database design, and one is > naturally rewarded with its inherent headaches. Does OO Base consider > normalization less of a value at GUI level?
Well ... I think it boils down to: - Since kind of data happens in real life (and it does!), should OOo silently destroy it, and afterwards argue "you did not normalize your database design, so it's your fault!"? OR - Should OOo prevent this from happening, at the cost of imposing additional restrictions on the kind of data it *can* modify? Long ago it was decided that the second way would be better. This doesn't mean that it isn't debatable, but it's the current state, with a reasoning which is not per-se wrong, IMO. > 2. set notion based SQL construct > ... > field 03 | field 07 | field 09 > (number) | (text) | (number) > ------------------------------ > 1 | name 04 | 17 > 1 | name 04 | 23 > 2 | name 07 | 23 (which in turn implies that OOo > ... > -- begin quote from Frank Schönheit > > 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. > > -- end quote from Frank Schönheit > > I am confused here by your comments. I shall assume that the second > paragraph of your comments results from an assumption that the two > examples were connected. The concern would not exist in a normalized > database design. So I shall skip this part. Yes, in fact my assumption somehow was that "field 03" and "field 07" originated from a "flawed" table as in the first example. > Now about the first paragraph on how to update the data. In R-DBMS, > it has been designed on set theory that data are manipulated as a set. > The set may contain only 1 member satisfying the criteria. It is > still a set. SQL language design has followed the same spirit. This > needs some effort to get used to for programmers who are so engrained > in notions of iterators in Java, C++, C, etc., which are a variant of > pointers in C and C++. > > I assume that OO Base always interacts with the backend DBMS engine > through SQL CUI. Or is this assumption wrong? > > The answer by SQL to your question in the first paragraph would > effectively be (save the actual SQL statements): > > Change the content of "field 07" to "name 08" for all records whose > associated "field 03" is "1" and "field 09" is "23". > > The key notion here is "for all records". Notice the absence of > position info. in this statement. In set based operations, no info. > of static position (index) of any sort (row, line, character, etc.) is > passed to DBMS engine. In SQL, The DBMS engine does not take any > position info. from GUI. Nor does it provide the position info. back > to GUI. The GUI does not need to, and does not, provide position info. > to manipulate data, because they are treated as sets. The GUI is free > to construct all kinds of position info. (bookmark, index, etc.) for > its own use. Surely the DBMS engines also construct their own > internal position info. as they work through the dataset (need to > support rollback, etc., in transactions). However, no position info., > regardless of the origin, is ever exchanged. Yes, that's the technical concept. But to the average end-user (not the database expert knowing about those theories!) it boils down to: I have a set (sic!) of rows being shown to me, I enter some data in one (!) of them, and if I tomorrow look at one of my tables, suddenly more than one record has changed. Why? Didn't I modify just one record in the GUI?" It's the GUI which Joe Average interacts with, and as correct a set-update would be by technical definition, as incorrect would it be from Joe's perspective. Which again leads us to the two alternatives above, on how OOo should solve this dilemma. > One reason for this set approach is to support transactions, rollback, > and multiple writers and readers. The DBMS engine is free to change > the location of any records in a transactional system with multiple > simultaneous clients, some being writers and some being readers. The > notion of position info. is like pointers in C and C++ languages, if > this comparison helps. Think about the consequence and why the Java > language designers have chosen to leave out the concept of pointers. > (No flame please. All programming languages have merit and > limitation.) It's not really about pointers an positions, IMO. It's that this theory about sets of records is not the kind of concept you find in Joe's head. For Joe, it's "the record with the following data", and he doesn't even think about the fact that "record" could potentially be "records". > -- begin quote from Frank Schönheit > > 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.) > > -- end quote from Frank Schönheit > > Please let the community know which DBMS engine product has been > re-designed as suggested to allow direct data access through position > info. Database design experts will weigh in on such design whether it > constitutes vulnerability or added value. It should be interesting to > find out if those DBMS engine products gain or lose market share. Please stop calling this "position info" :). It's "bookmarks", a well-known concept in a lot of database access APIs. A bookmark is a special value associated with a row, which is not interpreted by the client, but is guaranteed to uniquely identify this row. Backends are free to implement this using "position info" which is very specific to the way they actually store the data, but they must not. Actually, there are few drivers I know which really support bookmarks. OOo's own dBase implementation does, but this is probably not really an argument :). Microsoft's ODBC and ADO drivers for Microsoft Access databases does, as well as SQL Server's ODBC driver (all IIRC). Not sure about PostgreSQL's ODBC driver ... 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]
