Mandi! Bazile Lebeau In chel di` si favelave... > - the structure of the data base will become increasingly complex > and the number of requests to the use will increase exponentially > according to the addition of functionality.
...but in the same time computers will became more powerfoul and less expensive. ;) > - We will see users managing very big parks (more than 20 000 > stations on a hierarchie of distant sites). AFAIK the problem in web interfaces are not really the database speed, but the generated page that grow to a size that became a bloat. There's no database optimization that can cure this, only global overral optimization, and faster servers and lines. ;) [concisely, the problem are not the processing of the information, but the information itself!] > To face these problems the database will have to evolve to an adapted > model ensuring a maximum of integrity for the data. This imply relational model? Cool... very good choice! ;) > The solution come from it, it will be necessary to pass towards > more adapted physical structure, by integrating complétement > principles such as the triggers, stored procedures, view and other > concept managed by the DBMS him even. With triggers? Yesss!!! ;))) > This at the head we wait with impatient the arrival of MySQL > 5, which seems in our mind, to answer perfectly these needs and constraints. > This it is not a fixed position, and it is always wise to discuss > it and to have the opinion of each one. ...we can start a flame? ...please, a flame... a f-l-a-m-e!!! ;) [do you remember Obelix when encounter the rome troops? ;] Why wait for something, when you can get NOW postgresql 8 that have all this, and much more? ;-))) > We ruled by mutual agreement and after a long discuss that > the use of layer of abstraction, or the migration just as it is > (without real change in the physical model of the data, nor use of the > tools provided by the DBMS) will not bring anything on the long term > to the project, and on the contrary will be even in contradiction with > our prospects for evolution whose reasons are quoted higher. Seriously: + i think that tighteen the database schema with stron relationaly will add true value to glpi + also using database features like triggers and view is very good. + there's databases and databases, someone better then others, but mysql are surely a good chice (for simplicity and widen of use) But i think that all of this are not coons of database indipendence: + because views are now supported by a wide range of database + because triggers are transparent to the aplication, they are schema attribute, so pose no one problem (apart installation and upgrade) Instead, db indipendence could lead to better code, ad also more user base, so more bug reports and so better code again. ;) Clearly you (glpi team) could state clearly that glpi support only database that have relationality, have views and triggers, and also that the team support MySQL, leaving to external the support (in the sense of making schema and install/upgrade scripts ;) of others db. So... i hope will be room to rethink about this, also because AFAIU there's just someone that are working on a postgres/adodb/... glpi version, and leaving this patch now out of code, to wait for a future event, i think it will be a real mistake. My two cents. Hem, sesterzi. ;) -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) gaio(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Grazie, Polonia! http://thankpoland.info/
