Si je connais le format correct des champs, devrais-je créer des contraintes de contrôle pour tous ces champs ou cela affectera trop la performance des insertions / mises à jour trop? Serait-ce une bonne idée d'utiliser des expressions régulières pour des règles complexes ou devriez-je utiliser uniquement des contraintes simples comme le cas et la longueur?
Les champs sont déjà validés au niveau de l'application.
8 Réponses :
En général, il est préférable de ne pas faire confiance à l'application et d'utiliser les contraintes de chèques. Les données doivent maintenir l'intégrité (qui sait ce que le script rogue peut exécuter, ou quel bug de programme peut glisser).
Toutefois, si vous avez de nombreuses contraintes de contrôle complexes et que vous remarquez un ralentissement de l'insertion / mise à jour, vous voudrez peut-être réévaluer. Est-il vraiment nécessaire d'en avoir un sur chaque domaine? Non, le type de données et la longueur de la colonne agissent également comme des contraintes.
Cela dépend de votre niveau de paranoïa.
Bien sûr, des vérifications de double vérification sont meilleures que des contrôles simples, mais la vérification du côté client présente l'avantage ou la parallélisation. p>
Les contrôles latéraux du client sont effectués. Par beaucoup, éventuellement des milliers d'ordinateurs que vos clients utilisent, tandis que les vérifications côté serveur sont effectuées par le serveur unique. p>
Je vient d'exécuter un test sur mon oracle 10g code>: P> CREATE TABLE t_check (value VARCHAR2(50) NOT NULL, CHECK(REGEXP_LIKE(value, '^[0-9]{1,10}$')))
INSERT
INTO t_check
SELECT level
FROM dual
CONNECT BY
level <= 1000000
"Cela dépend de votre niveau de paranoïa.
Bien sûr, les vérifications de double vérification sont meilleures que des contrôles simples, mais la vérification du côté client présente l'avantage ou la parallélisation.
Les vérifications latérales du client sont effectuées par de nombreux ordinateurs que vos clients utilisent, tandis que les contrôles côté serveur sont effectués par le serveur unique. "
Bien que rien de tout cela ne soit faux en soi, cette réponse semble souligner de manière luziquement l'importance de ces 25 secondes et semble donc plutôt biaisée vers "compter sur les clients". C'est imprudent, période. Surtout si le coût d'un million d'inserts est aussi négligeable que 25 secondes. Vous ne savez jamais si tous les clients implémenteront correctement tous les chèques nécessaires, et même si vous savez que pour les clients qui existent actuellement, même vous ne connaissez pas d'autres clients futurs.
Ce que vous devez prendre en compte est le coût de réparation que vous encouragerez lorsque vos données sont "corrompues" à la suite d'une certaine contrainte qui n'a pas été appliquée par le système de base de données. Par exemple, réfléchissez si le "pauvre gars" qui a dû résoudre le problème suivant ( Recherche GUID dans la base de données ), serait fait en 25 secondes.
Si la somme totale de temps nécessaire pour effectuer toute la vérification des contraintes rend vos transactions sensiblement plus lentes, même il est probablement plus conseillé d'essayer de convaincre votre organisation d'investir dans un matériel plus ou plus rapide .
Les données garanties pour satisfaire les règles d'intégrité sont l'actif le plus important dans la plupart des entreprises aujourd'hui et devrait être chéri en tant que tel.
"C'est une période imprudente. Surtout si le coût d'un million d'inserts est aussi négligeable que 25 secondes." Cela dépend de la fréquence à laquelle vous insérez un million d'enregistrements, n'est-ce pas. Quassnoi souligne que dans certaines circonstances, vous pourriez envisager de ne pas utiliser de contrainte de contrôle. Point valide IMHO.
Cela dépend également du degré de contrôle et de responsabilité que vous avez sur le logiciel client. Si vous êtes le DBA qui est responsable de l'intégrité globale des données, mais vous n'avez aucun contrôle sur ce que font les applications client, vous n'ayez pas d'autre choix que d'être paranoïaque et d'appliquer toutes les règles qui, si elles sont cassées, ID allait être pris comme un défaut d'empêcher la corruption des données.
Si, d'autre part, vous écrivez toutes les applications ainsi que la base de données que ce qui vous permet de faire respecter les règles, ou éventuellement aux deux endroits. Une règle que j'ai presque toujours utilisée pour appliquer dans les deux endroits est la règle non nulle. Il ne devrait pas prendre un aller-retour sur le serveur pour savoir que certaines données requises sont manquantes. Mais cela ne coûte presque rien pour le vérifier au niveau de la base de données.
Cela dépend vraiment de votre architecture globale. Si votre base de données est utilisée strictement comme un magasin de données, il ne devrait pas y avoir de vérification de la base de données.
Le fait que vous posiez à cette question suggère que vous utilisiez la base de données de manière plus traditionnelle. Dans ce cas, il est généralement préférable d'ajouter autant de contraintes que possible sur la base de données, puis de voir lesquelles il faut être supprimé pour améliorer les performances (à quel point vous devez décider si le boost de performance vaut la sécurité réduite).
Voulez-vous dire ce double négatif? "Si votre base de données est utilisée strictement comme un magasin de données, il ne devrait pas y avoir de vérification de la base de données."
Les points de Quassnoi concernant sont valables, mais il convient de rappeler que tous les contraintes sont égaux. Dans les tests suivants, j'ai comparé le "Les tests" muraux "sont sensibles aux conditions ambiantes ( comme un coup de contrôle) afin que nous ayons besoin de les exécuter plusieurs fois. L'autre chose à garder à l'esprit est que la performance peut varier d'une version à la version. Par exemple, je suis en cours d'exécution sur 11g et le chèque de regex a systématiquement sur 9-10 secondes , qui suggère Oracle l'a optimisé considérablement depuis 10g. D'autre part, les inserts non cochés ont couru à 1,7 - 2-ISH secondes , donc regex est encore relativement coûteux. Les autres chèques ont pesé à peu près 2,5 à 3,0 secondes , qui est à environ 50% d'intégrité pour l'intégrité. s'il vaut la peine de payer que le péage dépend vraiment de la façon dont vous pensez vos données. L'expérience indique que compter sur le client de faire respecter les règles de données signifie inévitablement que, à un moment donné, les règles seront cassées . Soit parce qu'un développeur omette de les appliquer ou les supprime de l'application. Ou parce que quelqu'un attache à la base de données une nouvelle application cliente (E.G. Upload Batch, service Web) qui n'inclut pas ces règles. Enfin, la plupart des applications ne vont pas charger un million de lignes à la fois. Par rapport à l'aller-retour au réseau, les microsecondes nécessaires à l'application des chèques à un seul insert ou à un téléchargement sont probablement une surcharge triviale. Regexp_Like () Vérifiez que deux autres contrôles "à l'ancienne"; Le premier convertit la valeur en une chaîne de zéros, puis une vérification de l'égalité et la seconde fonctionne une vérification de la plage en utilisant entre () .
"Enfin, la plupart des applications ne vont pas charger un million de lignes à la fois ..." Tout à fait: imaginez que nous chargons 1 million de lignes par an, il ne vaut clairement pas la peine de risquer l'intégrité des données pour économiser 27 secondes sur une année!
Les applications qui chargent un million d'enregistrements à la fois sont celles qui nécessitent la plupart des contraintes de contrôle, car ces importations ne proviennent probablement pas de l'application, mais d'une application ETL à la place. Sans contrainte, il est très facile de charger de mauvaises données car les spécialistes de l'ETL sont moins susceptibles de connaître les règles commerciales de l'application à appliquer.
Ma vraie question à vous est, les données peuvent-elles entrer votre base de données à partir d'une source autre que l'application? Y aura-t-il de grandes importations ou des requêtes exécutées à partir d'autres applications ou d'une fenêtre de requête? Si vous avez reçu un nouveau client qui souhaitait importer des enregistrements du vendeur précédent, comment cela serait-il traité? Si vous pouvez concevoir une OPF une raison pour laquelle les données peuvent être modifiées de l'extérieur de l'application et que les règles doivent être appliquées pour toutes les données, vous avez besoin de vérifier les contraintes de contrôle ou des déclencheurs pour appliquer cela. Quelle est l'importance du format de la manière dont le reste de l'application fonctionne? Forinstance Si vous stockez tous les numéros de téléphone en tant que numéros et ajoutez la mise en forme de la page affichant les données, quel sera l'effet si une personne ajoute un numéro de téléphone (111) 111-1111 à vos informations affichées. L'intégrité des données est une partie critique des bases de données. Si vous ne pouvez pas compter sur les données dans le format correct ou suivez les règles correctes (seulement trois valeurs correctes pour un champ, par exemple), votre dqata devient moins précieux. En fonction de la gravité, cela pourrait être un échec essentiel.
Une autre chose à considérer est que vous avez des personnes qui peuvent accéder directement aux tables qui ne sont pas des administrateurs? Si tel est le cas, les règles appliquées au niveau de la base de données peuvent aider à réduire la fraude de la possibilité. (Le développeur oublie souvent de protéger les données des utilisateurs autorisés. Les règles dont je parle ici sont plus probables appliquées par des déclencheurs que de simples contraintes de vérification, à l'exception des limites supérieures des charges, mais c'est quelque chose à prendre en compte lors de la conception de la base de données)
La confiance est bonne, le contrôle est meilleur.
souvent, vous n'avez pas besoin de Reg EXPS du tout. Voyez ici pour un exemple: expressions régulières _ # à la fin de la chaîne . Substr, Traduire, Instr ... sont puissants et rapides.
La différence de vitesse dépend beaucoup de votre matériel - les processeurs, la mémoire, les disques et même la libération de la base de données peuvent affecter les contraintes / aucun rapport de temps de contraintes. Je vois une grande différence en nombre (pour cent sage) sur différentes combinaisons matériels-OS. La réponse correcte consiste donc à tester votre implémentation spécifique avec et sans constations et à comparer l'émission avec le coût du support d'assistance ou le nettoyage des données pour corriger les "mauvaises données", ou les deux.
Si vous avez déjà été chargé de migrer des données de la base de données où toutes les contraintes ont été "implémentées du côté du client", vous deviendrez véridi à la mise en œuvre des constarintes possibles sur le serveur.
Il serait extrêmement dangereux de croire que vous n'aurez aucune application avec une application utilisant vos données et toutes les mêmes "contraintes". Mais même dans ce cas, différents développeurs ont des connaissances différentes et avec le vieillissement d'applications et de défélégeurs, de nouveaux développeurs peuvent ne rien savoir sur certaines contraintes cachées dans des années de développement de code.
Ainsi, en d'autres termes, lorsque la conception pense "pourquoi nous n'avons pas besoin de cette contrainte" au lieu de "pourquoi nous en avons besoin" et teste le roi.