Chris Date, l'un des pères du modèle relationnel pour la gestion des données, m'a dit une fois que "Toute la théorie relationnelle est construite sur le calcul prédicatif."Nous accumulons des déclarations factuelles jusqu'à ce qu'elles créent une description de la réalité. Les humains sont tous des contes d'histoires d'une manière ou d'une autre.Nous adaptons le récit à notre vie quotidienne et à notre travail quotidien. Si vous définissez une table de base de données et que vous ne pouvez pas raconter l’historique des données, vous faites une erreur. Un regard sur les noix et les bolts du récit Les bonnes histoires suivent les règles. Pixar empile célèbrement les éléments d'une histoire dans une formule qu'ils appellent une colonne vertébrale de l'histoire: « Once upon a time... » « Et chaque jour... » « Jusqu’à un jour... » « Et à cause de ça... » « Et à cause de ça... » « Jusqu’à la fin... » Et depuis ce jour-là... » On pourrait penser à cette colonne vertébrale de l'histoire comme le modèle pour le bon récit. Suivant les « règles » du récit, c’est pourquoi nous voyons Woody comme un héros plutôt que de la poubelle, Remy comme un artiste plutôt qu’une violation du code de la santé, et Nemo comme courageux plutôt que désespéré. Il y a beaucoup d’opportunités pour la créativité dans les règles de ce modèle.Les narrateurs qui internalisent les règles du bon récit sont recherchés pour créer de nouvelles histoires et de nouveaux films. Certains réalisateurs, écrivains et producteurs peuvent s'écarter de ces meilleures pratiques de récit pour raconter des histoires qui ne correspondent pas au modèle de récit standard, mais les films qui manquent d'une histoire claire échoueront à la caisse à chaque fois, même s'ils sont magnifiquement filmés. Comment nous ingénieurs les histoires avec les données Dans le monde de la technologie, comme à Hollywood, nos histoires ne sont pas seulement écrites; elles sont agies.Nous instruisons les électrons à sculpter des runes dans des structures que nous définissons.Autres techniciens ou travailleurs du savoir peuvent se référer à ce que nous avons fait pendant des années à venir. Le modèle relationnel de gestion des données qui et définie dans les années 1960 et 70 a résolu de nombreux problèmes qui avaient existé avant sa création. SQL Server, Oracle, Snowflake, Redshift, MySQL, Clickhouse, Cockroach DB, DuckDB, et plus encore ne serait pas sans le travail de ces deux messieurs. Chris date par Ted Codd Voici un exemple de tableau tiré de leur livre, Introduction aux systèmes de base de données : EMP# ENAME DEPT# SALARY E1 Lopez D1 40K E2 Cheng D1 42K E3 Finzi D2 30K E4 Saito D2 35K EMP# ENAME DEPT# SALARY E1 Lopez D1 40K E2 Cheng D1 42K E3 Finzi D2 30K E4 Saito D2 35K L’EMP Unité Dépêché # Salaire Dans l'abstrait, ce prédicat est défini comme: « L’employé EMP# s’appelle ENAME, travaille dans le département DEPT# et gagne un salaire de SALARY. » Concrètement, nous pouvons l’interpréter comme : « L’employé E1 s’appelle Lopez, il travaille dans le département D1 et gagne un salaire de 40 000 $. » Il est facile de raconter l’histoire des données que cette table représente, c’est ainsi que vous savez que vous le faites correctement. Pourquoi l'IA ne peut pas résoudre les problèmes de performance de votre base de données J’ai été amené de temps en temps dans des situations où les performances des bases de données étaient considérées comme mauvaises, juste pour découvrir que les structures de données que les développeurs d’applications avaient créées ont complètement ignoré des décennies de règles de bonnes pratiques bien documentées qui assurent un récit efficace. Si les développeurs d’applications ou même les utilisateurs d’entreprise écrivent les prompts que nos outils de traitement de texte et de génération de texte utilisent, ces outils généreront du texte qui doit ensuite être incorporé dans le code de travail réel et des structures de données stables. Sauf si les personnes qui mettent en œuvre ces règles les comprennent et leur raisonnement, la seule chose qui arrivera est que les structures de données qui fonctionnent mal seront créées plus rapidement. Que votre rôle soit l’architecte, le développeur, l’ingénieur, l’utilisateur ou tout autre titre qui pourrait survenir dans le futur, vous êtes en dernier ressort responsable de ce qui persiste, est stocké, représenté et utilisé pour résoudre les problèmes futurs. Revenir à ces meilleures pratiques, qui existent depuis des décennies, vous rendra un constructeur meilleur et plus créatif. C’est comme ça que tu fais ta marque Oui, vous êtes une petite partie d'une entreprise. Néanmoins, vous voulez laisser votre propre empreinte sur le monde, n'est-ce pas? Whitman a posé une question similaire dans son poème « O moi, O vie ! » "What good amid these, O me, O life?" La réponse pour nous tous est : "That you are here—that life exists and identity, That the powerful play goes on, and you may contribute a verse." Quelle histoire déciderez-vous de raconter ? Si vous êtes un flocon de neige Administrateur de base de données ou Ingénieur de données , DataOps.live peut vous aider. Commencez dès aujourd'hui — Vous bénéficiez de 500 minutes gratuites par mois ! Administrateur de base de données Ingénieur de données Vous bénéficiez de 500 minutes gratuites par mois !
