/* English version in second part Look for **ENG BEGIN** */ Le Dimanche 8 Mai 2005 12:06, alexandre lemiere a écrit : > Si j'ai bien compris votre point de vue, le modèle de la base de donnée va > etre amené à évoluer vers un modele plus complexe et vous auriez besoin > d'utiliser les fonctionnalités tels que les triggers, procédures stockés, > vues.
C'est également ce que j'ai cru comprendre. Il est vrai que la base actuelle est relativement simple par rapport à certaines autres (eGroupware avec 268 tables et plus de 3500 champs et des jointures de 6 tables). > C'est un fait que ces fonctionnalités ne faisant pas parti de la norme SQL > (ISO), il est difficilemment envisageable de supporter plusieurs SGBD. > Chaqu'une de ces fonctionnalités devant etre implantée dans un langage > spécifique à la base. C'est à la fois vrai et faux. La plupart des SGBD modernes supportent les triggers, les procédures stockées et les vues, bien qu'aucune syntaxe normalisée n'existe. Sur le papier, les procédures stockées apportent un surcroit de performances, mais en contrepartie, on devient tributaire d'un SGBD, quand ce n'est pas d'une version (ceux qui ont du migrer du Progress en savent quelque chose). Les vues peuvent être émulées sans difficulté aucune pour les SGBD ne les supportant pas. Mais ces mêmes vues peuvent, selon le type de SGBD être uniquement en lecture seule, ou permettre lecture et update... à grand coups de triggers. C'est ce qui fait dire que l'utilisation de ces "extensions" non normalisées forcent le type de SGBD utilisé. > Néanmoins etes vous certain que les evolutions rendent obligatoires ces > fonctionnalités hors normes ? L'utilisation des mécanismes tels que clés > primaires / clés étrangères et l'utilisation de transactions (supportées > par AdoDB) ne peuvent-elles pas suffir à assurer l'intégrité des données ? Tout dépend du modèle conceptuel développé. Si l'on s'en tient à une stricte règle SGBD relationnel, alors la logique triggers, procédures stockées, etc. tient la route. Par contre, si on s'oriente vers une conception de type multi-tier ou plus radicalement objet, avec le SGBD utilisé en tant que simple dépôt d'objets, triggers et autres éléments non standards du SQL peuvent être ignorés. AdoDB est un pas intéressant dans cette direction. > D'autre part, avez vous pensez au fait qu'un code situé d'une part dans le > SGBD et d'autre part dans les scripts PHP est plus difficile à > suivre/maintenir/faire évoluer ? Question on ne peu plus pertinente. MySQL n'aura peut-être pas les problèmes rencontrés avec d'autres SGBD pour lesquels le changement de version impose l'utilisation d'un kit de migration qui ne corrige pas automatiquement l'ensemble des incompatibilités, surtout dans la gestion des procédures stockées (Oracle 7 => Oracle 8i par exemple). On pourrait objecter que le fait de stocker la logique de manipulation des données dans le SGBD permet de s'interfacer plus facilement avec divers langages, mais comme ce cas de figure est très rare, on peut presque l'ignorer sans trop de risques. > Si votre souhait est de pouvoir répondre au besoin des grosses structures > avec plusieurs milliers de poste, il me semble judicieux de pouvoir > supporter des bases à licences commerciales (MSSQL, Oracle) qui sont trés > souvent utilisées chez les grands comptes. Tout à fait d'accord. Dans ce cas, l'utilisation d'une couche d'abstraction est indispensable. Suivant les comptes, la faveur va vers Oracle, DB2, Progress, MS SQL Server ou encore Informix ou Ingres 2. Il serait inconcevable d'avoir des versions spécifiques pour chacun de ces SGBD. > D'expérience, je pense qu'un bon design de la base et l'utilisation de > transactions suffisent à assurer l'intégrité des données. Je suis totalement de cet avis. > En ce qui concerne les performances, le design est primordiale. Je ne pense > pas que les trigers, vues et procédures stockés changent vraiment la donne. C'est certain. Il existe des applications de gestion commerciale qui utilisent MS SQL Sever, mais qui s'effondrent littéralement dès qu'on dépasse une vingtaine de connections. Et, d'un autre côté, des gestions de travail collaboratif (eGroupware par exemple) qui n'utilisent ni triggers, ni toute la quincaillerie et tiennent le choc avec plus de mille connexions simultanées. > NB : AdoDB donne la possibilité de compiler une requète dans le cas > d'exécutions répétées au sein d'un script. (cf prepare). Et capable d'émuler pour les SGBD ne disposant pas de cette pssibilité (MySQL 4.0) > Un mécanisme de cache (cf CacheExecute) pourrait etre mis en place pour les > requètes dont les données changent raremment. (facile à mettre en place > avec adoDB, cf CacheExecute). Le cache serait effacée par le script qui > s'occupe de la mise à jour des données concernées. Ce mécanisme de cache est par ailleurs d'une redoutable efficacité. /* **ENG BEGIN** */ > If I understand your views, database model will evolve to something > more complex and you'll need functionalities such as triggers, stored > procedures and views. It's exactly what I understood, too. It's true that the current database is pretty simple if we compare it with some others (eGroupware with its 268 tables and more than 3500 fields and 6 tables joins). > As a matter of fact those functionalities are not described in ISO SQL > standard, it is hardly imaginable to support many Database Servers. > Each and every functionality having to be implemented in the database > specific dialect. It's both true and false. Most modern database have a support for triggers, stored procedures and views, while no syntax normalization exist. On the dashboard, stored procedures are more performant, but they imply that we are stuck with a database engine, when not of a version of it (those who had to migrate Progress know about this). Views can be emulated easily when database negine does not support them. But, according to the engine, the views may be read-only or read-write... providing you feed them with your own bunch of triggers. This is why it is a common say that using those not standardized 'extensions' force a unique storage engine use. > However, are you sure that these evolutions require those non standard > functionalities ? Using mechanisms such as Primary Keys / Foreign Keys > and using transactions (supported by AdoDB) would not suffice ensuring > data integrity ? This depends on conceptual model. If one tries to be strictly relational model compliant, then a logic using triggers, stored procedures,... is rock solid. But, if one tries a concept using multi-tier or a more radical object model, with the database used as an object repository, then non standardized SQL elements may safely be ignored. AdoDB is an interesting step in such a direction. > On the other hand, did you weight that code broken in pieces with parts > in database and parts in PHP scripts is harder to maintain/upgrade ? This is a pertinent question. MySQL might not have problems we met with other databases where version upgrades may impose migration kit use, kit not completely converting incompatibilities, maily stored procedures (Oracle 7 to Oracle 8i is an example). One can say that string data manipulation logic in the database allow an easier port to various programming languages, but experience shows this is very rare, so we can ignore it without great risks. > If your wish is answering huge structures with thousands of workstations, > it seems judicious offering support for commercial licensed database > servers (MSSQL, Oracle) which are very often used in Corporations. I'm 100% with you. In such a case, using an abstraction layer is a Must Have. Depending on companies, Oracle, DB2, Progress, MS SQL is favored, and even Informix or Ingres 2. It is not conceivable to maintain separate versions for each and every database server. > From experience, I think a good database design and transaction use is > enough to ensure data integrity. I totally agree with you. > About performance, design is the primary target. I don't think triggers, > views and stored procedures change things radically. Sure. We found some business management apps using MS SQL, with dramatic performance drop as soon as we have more than 20 simultaneous users. On the other hand, some groupware apps (such as eGoupware) which don't make use of triggers, nor all the other stuff but can handle more than thousand simultaneous users without performance loss. > NB : AdoDB allows query compilation for repeated use in a script > (cf prepare). It even allows a prepare emulation for database without this feature (ie MySQL 4.0) > A cache mechanism (cf CacheExecute) could be used for quasi static data. > (This is easy to setup with AdoDB, cf CacheExecute). Cache would be > cleaned by data update script. This cache mechanism shows a redoutable efficiency. -- JCR aka DJ Anubis LAB Project Initiator and coordinator
