Re: ANSI databases

>>>>> On 7 Mar 1994 13:13:07 -0500, johnl@informix.com (Jonathan Leffler) said: > What Dave Kosenko said is all correct, though I would dispute whether > the "most notable" item is the transaction behaviour or the fact that if > the person running the application doesn't own the table, the table must be > referenced by 'owner'.tablename -- that is a far bigger headache in my > view, though the transaction behaviour is also significant. Sorry Jonathan, I usually appreciate your hints and comments (in my view you really add value to this group), but this time I would like to express an entirely different standpoint. I would not exactly call owner naming a headache. Think of namespaces. Identifiers in Informix-SQL are pretty short (18 characters) when it comes to modeling complex business situations. So owner names can be quite useful to split the names into distinct modules. A practical example (that's the way we work here): Assume a collection of integrated software (accounting, payroll, order processing, etc.). You have several applications, each with its own set of tables. The applications also use common tables to share information (the integrating interface). The applications are developed by independent teams (sometimes even independent companies), cooperating on the interface between applications where necessary. The owner of an application's table set is the name of the application. A special owner for application independent (shared) tables also exists. This way we only have to worry about keeping table names unique within *one* application. The table sets can be maintained independent of each other (shared tables excluded). This is a current snapshot of 4 applications with a total of 289 tables: owner | number of tables AKTIVA | 75 (accounting) IMPULS | 72 (order processing) TARIF | 87 (payroll) INFIX | 55 (shared: addresses, etc.) When we switched to ANSI mode it really made maintenance a lot easier. > There are all sorts of other oddities to watch for. [description of some documented ANSI standard features deleted] We had to convert large applications from non-ANSI to ANSI-SQL. Yes, some things are different but it's all sort of getting used to. For example we had consistency checks after DELETE and UPDATE statements that generated errors if there were no rows processed. Now we use the SQLNOTFOUND code instead. A major problem during conversion is code that heavily relies on implicit single-statement transactions (outside begin-commit blocks). > Summary: I wouldn't touch a MODE ANSI database unless I had to. I really disagree. > And I'd expect all sorts of interesting little problems arising out > of the ANSI standard. Our experiences are different. To be fair, please note that some interesting little problems arise out of the Informix implementation of the ANSI standard. Example: while table names have to be unique for an owner, index names have to be unique regardless of owner. Summary: I hope Informix continues to follow ANSI standards and considers them not just as governmental buyer's checklist items. -- Oliver Okrongli infix Software-Systeme GmbH Phone +49 531 238090 Rebenring 33 Fax +49 531 2380935 oliver@infix.de 38106 Braunschweig F.R. Germany