Discussion :

[ordigil]

Bonjour escartefigue Merci beaucoup pour votre petite visite

Et surtout un gros merci à fsmrel qui est encore là malgré les nombreuses heures qu'il a passé sur ce projet d'étude qui est un des cours les plus complet que je n'ai jamais reçu. Ça ne devait être qu'à l'origine qu'une petite base données des plus banale et oupsssss fsmrel est intervenu et je ne me lasse pas de ses interventions. Comme dans toute chose, lorsqu'on fait les coins ronds, nos erreurs ou notre négligence nous rattrapent toujours. Des choses sans importance à l'origine deviennent plus importantes à mesure que la base de données prend de l'ampleur et que les choses évoluent ici sur le terrain. À chaque fois que fsmrel trouve une solution, je dis ahhhhh aussi bien d'y incluse autre chose aussi puisque nous y sommes. Cette base de données qui à l'origine ne devait que remplir un besoin pour un petit atelier devient un outil universel qui pourra être utilisé dans de nombreuses petites entreprises.

Pour les petits pouces en l'air, je vais refaire la tournée ce weekend car oui fsmrel les mérite. Je travaille de nombreuses heures par semaine et aussitôt que j'ai 15 minutes pour venir sur developpez.net je viens lire et étudier ce que fsmrel y a ajouter ou corriger ou me discipliner. Là je suis complètement dépassé, j'ai peine à suivre l'évolution de la BD. Je n'ai pas beaucoup de temps libre, j'ai beaucoup de travail ici. L'hiver est arrivé et j'ai beaucoup à faire, je dois terminer la réparation du loader (chargeur sur roue). Je dois courir après les pièces et respecter le budget que le patron m'a donné. Les petits pouces s'en viennent fsmrel, vous les mériter tellement. Merci d'être encore là pour moi. Je dois trouver aussi du temps pour donner une petite formation en informatique à un de mes fournisseurs. Il y a un très gros problème dans les ateliers de réparation, les techniciens branchent leur ordinateur à l'ordinateur de votre véhicule mais ils ignorent totalement comment un ordinateur fonctionne. Vous ne pouvez pas vous imaginer le nombre de pièces qui sont changées et qui vous sont facturées lorsque vous allez chez un concessionnaires alors que les pièces changées n'ont aucun problème. Les pièces sont changées car les techniciens n'ont aucune idées comment fonctionne un ordinateur. Les petits pouces s'en viennent fsmrel.

escartefigue, vous êtes toujours le bienvenue pour apporter des commentaires et merci d’encourager fsmrel dans ce projet. Vos visites sont très appréciées. D'un côté j'ai fsmrel qui me dit non c'est pas ça, et de l'autre côté l'utilisateur me dit non c'est pas ça. hahaha Donc je dois faire en sorte que la théorie de fsmrel rejoigne quel que peu la façon dont un technicien raisonne, nous devons automatiser au maximum le fonctionnement de la base de données et ne demander que le minimum d'effort à l'utilisateur via les formulaires. L'utilisateur est encore au cahier et au crayon. J'essaie de concevoir l'interface de la façon dont il utilise son cahier et son crayon, ça amène beaucoup de contraintes

@Ordigil : je confirme que de nombreux de logiciels du commerce s'appuient sur un modèle de données défaillant, voire catastrophique dans certains cas et pas seulement les logiciels adressés aux petites entreprises, les grands compte chez qui j'interviens depuis de nombreuses années en sont aussi victimes. Pourtant ces très grandes sociétés disposent d'équipes informatiques internes qui devraient être en mesure de jauger la qualité du produit avant de signer le contrat, mais elles sont rarement consultées, l'enjeu financier et les relations privilégiées des fournisseurs avec les décideurs, ont bien plus de poids que la qualité et la robustesse du produit !

@François : je ne viens sur ce fil qu'épisodiquement, pour distribuer quelques points amplement mérités vu la qualité des interventions - comme à l'accoutumée - la pertinence et la précision du propos, le temps consacré et tout ça dans la bonne humeur.
Que dire d'autre que Bravo, Bravissimo !

@Ordigil : à ce propos, vous avez oublié quelques +1 au bénéfice de votre bienfaiteur, à corriger d'urgence, les votes positifs quand ils sont mérités sont toujours les bienvenus

[fsmrel]

Bonsoir Ordigil et Escatefigue,

Oui, c'est pour cette raison que j'ai inclus notre 'SHOP' dans 'CONTACT'

D’accord, et il ne faut pas que j’oublie de créer la relation entre LOCAL et SHOP.

e ne change jamais de OilBrand, OilRange, OilViscosity mais ok pour une table qui leur est dédiée comme dans votre diagramme...

En l’absence de cette table, appelons-la OIL_SPEC, l’« effet Batum » est garanti.

A ce jour, la table OIL_CHANGE (HUILE_CHANGEMENT) est en relation avec la table COMPOSANT, puisque tous les composants sont concernés. La mise en oeuvre de la nouvelle table OIL_SPEC peut être modélisée ainsi (désolé pour le mélange des langues...) :

Notez la présence du Code barre pour permettre l’accès à l’information (vous pouvez aussi préférer utiliser un code qui vous soit propre...)

Cela dit, cette modélisation pose un problème, au cas où à une date donnée on n’utiliserait plus la même huile. Vous me direz « On se sert toujours de la même ! » jusqu’au jour où finalement vous pourriez changer d’avis…

Dans cette hypothèse, selon le diagramme suivant, il est possible que pour le composant C1 on se soit servi de l’huile H1 à la date D1, et de l’huile H2 à la date D2 :

Il y aura beaucoup de travail à refaire dans les VUES pour les mettre à jour avec les Tables.

Ben oui, on est dans la soute, et comme disait le poète :

Hâtez-vous lentement, et sans perdre courage,
Vingt fois sur le métier remettez votre ouvrage,
Polissez-le sans cesse, et le repolissez,
Ajoutez quelquefois, et souvent effacez.

Mais sur le pont, rien de changé pour l’utilisateur et son interface

Je songe sérieusement à abandonner Windows 10 et le remplacer par Solaris ou Linux.... Quelle SGBD serait le plus près de SQL Server ???

Je ne connais ni Solaris ni Linux, mais avec ce dernier, le SGBD le plus près de SQL Server n’est manifestement autre que SQL Server lui-même ! Notre grand spécialiste SQLpro a pondu un article comparant SQL Server sous Linux et Windows.

Bravo, Bravissimo !

Merci Capitaine, grand merci ! Ça fait du bien pour le moral



@Ordigil, @Escartefigue

Allusion au poème de Jacques Prévert :

« Rappelle-toi cela Barbara
Et ne m'en veux pas si je te tutoie
Je dis tu à tous ceux que j'aime »

Me permettez-vous de vous tutoyer ?

Une anecdote au passage. Du temps où je faisais du conseil/assistance/enseignement/audit/réparation/réconfort/etc. (modélisation puis passage à l’acte avec DB2 ;-) ) auprès du CMB à Brest il y a 25 ans, je me chantais ce poème (à la façon des Frères Jacques), tout en arpentant la rue Siam le soir, avant d’aller déguster un bon tourteau, accompagné de langoustines de la Rade, puis de crêpes et tout ça…

A cette occasion, j’ai eu à consoler un développeur qui avait codé une requête SQL à l’usage de l’utilisateur, avec présentation à l’écran de la liste des clients dont le nom commençait par une certaine chaîne de caractères. La requête en particulier comportait un LIKE intéressant :

   LIKE 'Le G%'

Bien entendu, comme on était en Bretagne, une majorité de clients étaient concernés, c’est-à-dire des centaines de pages d’écran (tous les Le Gall, Le Goff, etc.) L’utilisateur et le développeur étaient en larmes, d’autant que les dévots de l’autre SGBD d’IBM se gaussaient... Mais la solution de contournement était assez évidente.

[ordigil]

On a de longs messages, je suis à peu près certain que ça ne nous attire pas de visiteurs LoL
Mais ils ne savent pas ce qu'ils perdent en formation


Donc on retient votre 2ième solution soit la Table OIL_SPEC avec la Table COMPONENT_OIL puisque nous avons abandonné la base de données personnalisée pour en faire une base de données universelle. 'OIL_SPEC', ça me dit quelque chose ce nom de Table là

Ne perdez pas votre temps avec les Vues pour le moment, nous n'en avons pas besoin pour le moment. On va essayez de terminer les Tables. Je me sens coupable à chaque fois que vous devez corriger les Triggers dans les Vues.

Code barre --> 'Barcode' sans espace, on garde le nom, le numéro du produit est dans le Barcode de toute façon.

Il y a de cela quelques années, je fabriquais des serveurs pour les petites entreprises et je connaissais Solaris et la plupart des distributions Linux qui pour plusieurs ont aujourd'hui disparues et d'autres ont vu le jour. Je ne suis plus du tout un spécialiste UNIX mais je vais m'y remettre un peu pour le plaisir car là, des ordinateurs sous Windows 10 en état de surchauffe uniquement en navigant sur le WEB, la comédie a assez durée. Ça devient ridicule... Un système d'exploitation qui prend à lui seul presque entièrement les ressources d'un ordinateur, disons que.... Bof passons... J'ai même la mémoire vive en état de surchauffe, il y a quelque chose qui ne tourne pas round dans Windows 10 et ça empire au fil des mises à jour au lieu de s'améliorer...

Pour SQL Server sous Linux :

SQL Server sous Linux, n'est pas encore un produit complet en soi d'après mes lectures sur le site de Microsoft, fonctionnel oui mais complet non, par contre je ne visite pas Microsoft à tous les jours. Et pour la gratuité, je ne sais pas s'il est gratuit sous Linux, je n'ai pas trouvé de lien. J'aime bien SQL Server, question sécurité, même si je l'expose volontairement sur internet au monde entier et que je reçois au minimum 1000 attaques par 24 heures, personne n'y a encore accédé.

Bien que je puisse obtenir Solaris gratuitement, je ne rencontre pas les critères pour l'utilisation gratuite du produit, alors je passe... Dommage, c'est un excellent produit.. Mais le respect de la licence oblige...

Je vais installer Suze Linux, des heures de joie assurées puisque j'ai pratiquement tout oublié de Linux.

Je pense PosgreSQL si je ne trouve pas SQL Server pour Linux...

Pour LIKE on raffine un peu

   LIKE 'Le G%'

Bonsoir Ordigil et Escatefigue,

D’accord, et il ne faut pas que j’oublie de créer la relation entre LOCAL et SHOP.


En l’absence de cette table, appelons-la OIL_SPEC, l’« effet Batum » est garanti.

A ce jour, la table OIL_CHANGE (HUILE_CHANGEMENT) est en relation avec la table COMPOSANT, puisque tous les composants sont concernés. La mise en oeuvre de la nouvelle table OIL_SPEC peut être modélisée ainsi (désolé pour le mélange des langues...) :

Notez la présence du Code barre pour permettre l’accès à l’information (vous pouvez aussi préférer utiliser un code qui vous soit propre...)

Cela dit, cette modélisation pose un problème, au cas où à une date donnée on n’utiliserait plus la même huile. Vous me direz « On se sert toujours de la même ! » jusqu’au jour où finalement vous pourriez changer d’avis…

Dans cette hypothèse, selon le diagramme suivant, il est possible que pour le composant C1 on se soit servi de l’huile H1 à la date D1, et de l’huile H2 à la date D2 :

Ben oui, on est dans la soute, et comme disait le poète :

Mais sur le pont, rien de changé pour l’utilisateur et son interface





Je ne connais ni Solaris ni Linux, mais avec ce dernier, le SGBD le plus près de SQL Server n’est manifestement autre que SQL Server lui-même ! Notre grand spécialiste SQLpro a pondu un article comparant SQL Server sous Linux et Windows.





Merci Capitaine, grand merci ! Ça fait du bien pour le moral



@Ordigil, @Escartefigue

Allusion au poème de Jacques Prévert :

« Rappelle-toi cela Barbara
Et ne m'en veux pas si je te tutoie
Je dis tu à tous ceux que j'aime »

Me permettez-vous de vous tutoyer ?

Une anecdote au passage. Du temps où je faisais du conseil/assistance/enseignement/audit/réparation/réconfort/etc. (modélisation puis passage à l’acte avec DB2 ;-) ) auprès du CMB à Brest il y a 25 ans, je me chantais ce poème (à la façon des Frères Jacques), tout en arpentant la rue Siam le soir, avant d’aller déguster un bon tourteau, accompagné de langoustines de la Rade, puis de crêpes et tout ça…

A cette occasion, j’ai eu à consoler un développeur qui avait codé une requête SQL à l’usage de l’utilisateur, avec présentation à l’écran de la liste des clients dont le nom commençait par une certaine chaîne de caractères. La requête en particulier comportait un LIKE intéressant :

   LIKE 'Le G%'

Bien entendu, comme on était en Bretagne, une majorité de clients étaient concernés, c’est-à-dire des centaines de pages d’écran (tous les Le Gall, Le Goff, etc.) L’utilisateur et le développeur étaient en larmes, d’autant que les dévots de l’autre SGBD d’IBM se gaussaient... Mais la solution de contournement était assez évidente.

[ordigil]

Bonjour fsmrel

Désolé pour le délai. c'est un peu difficile à gérer. Mais ça s'en vient tranquillement pas vite. il y a longtemps que je n'ai pas touché aux systèmes LINUX. Nous avons maintenant SQL Server fonctionnant sur OpenSuSE LINUX LEAP 15 2018 malgré quelques petites difficultés techniques éprouvés lors de l'installation... ScreenShot à partir de AZURE Data Studio

Premier ScreenShot

Pièce jointe 441537

[fsmrel]

Bonjour Ordigil,

Je me sens coupable à chaque fois que vous devez corriger les Triggers dans les Vues.

Si quelqu’un devait se sentir coupable, c’est plutôt celui qui a pondu SQL Server et n’a pas voulu qu’on puisse mettre à jour les vues impliquant plus d’une table et nous oblige donc à pallier sa carence pour ne pas se prendre un méchant :

Msg 4405, Niveau 16, État 1, Ligne 26
La vue ou la fonction 'xxxxx' ne peut pas être mise à jour car la modification porte sur plusieurs tables de base.

Pour mémoire, ce genre de mise à jour est prise en compte par la norme SQL.


De toute façon, les vues et les triggers vont subir des modifications, car je pense qu’il est temps de respecter la troisième forme normale ;-) , notamment avec la gestion des manufacturiers et de leurs modèles de matériels (cf. tables CAMION et COMPOSANT), surtout pour rendre la base de données plus apte à l’universalité qui vous interpelle :

Cette base de données qui à l'origine ne devait que remplir un besoin pour un petit atelier devient un outil universel qui pourra être utilisé dans de nombreuses petites entreprises.

Ainsi, manufacturiers et modèles disparaissent des tables CAMION et COMPOSANT pour devenir des objets de gestion à part entière, grâce à la mise en oeuvre des tables TRUCK_MANUFACTURER, TRUCK_MODEL, COMPONENT_MANUFACTURER, COMPONENT_MODEL. A noter que les manufacturiers sont des contacts.


Diagramme D1

Dans le diagramme D1, les attributs originels Manufacturer et Model des tables CAMION et COMPOSANT sont remplacés par les attributs TruckManufacturerId, TruckModelId, ComponentManufacturerId, ComponentModelId, lesquels référencent leurs homologues dans les tables TRUCK_MODEL et COMPONENT_MODEL.

A la réflexion, le diagramme D1 peut faire l’objet d’une transformation, au bénéfice du suivant :


Diagramme D2

Pour simplifier les requêtes SQL, la table MODEL comporte désormais un attribut ModelType permettant de savoir tout de suite si tel modèle de tel manufacturier concerne un camion ou un composant (c’est de l’optimisation...). Bien entendu, les triggers associés assureront en conséquence la cohérence de la valeur de cet attribut et des valeurs des clés étrangères des tables CAMION (ManufacturerId, ModelId) et COMPOSANT, par référence à la clé primaire de la table MODEL.

Je penche pour le scénario D2, mais vous pouvez — ainsi qu’Escartefigue — émettre des réserves.

Ça fait quand même étrange qu'il y ait beaucoup de redondance dans nos Tables comme les Numéros de séries dans chacune des Tables Truck, Engine, Transmission, Axle, Differential... Nous avons une colonne Manufacturier dans toutes les Tables alors que tous les Manufacturiers pourraient être regroupés dans une seule Table.

Concernant les manufacturiers, les diagrammes D1 et D2 ci-dessus devraient vous satisfaire.

Concernant les numéros de série , j’ai répondu dans le post #846 :

L’éparpillement des numéros de série est en phase avec la sémantique : un numéro de série de moteur n’est pas comparable à un numéro de série de transmission ou d’axle...

Cela dit, on peut quand même expulser les numéros de série de leurs lieux d’hébergement actuels et les regrouper dans la table COMPOSANT :


Diagramme D3

Si le regroupement des numéros de série vous convient (simplification de certaines requêtes), je vous suivrai et mettrai en place ce regroupement.

Je rappelle que, sous réserve de preuve du contraire, il n’est pas a priori exclu que pour deux manufacturiers, on doublonne sur les numéros de série, en conséquence de quoi, pour se mettre à l’abri, ce n’est pas le singleton {SerialNumber} qui sera clé alternative de la table COMPOSANT, mais plutôt le triplet {ManufacturerId, ModelId, SerialNumber}, voire la paire {ManufacturerId, SerialNumber}, mais le triplet est préférable, en effet on ne sait pas quelles idées peuvent traverser le crâne des manufacturiers…


Bon, maintenant il va falloir que je vérifie la faisabilité des modifications que je suggère dans tous ces diagrammes

[ordigil]

Bonsoir fsmrel :-)

Wouaouwwwww vous n'avez pas chômé

Oui, je ne comprend pas pourquoi Microsoft a voulu faire difficile quand c'est possible de faire facile

Entre le modèle #2 ou le modèle #3 vous choisissez celui qui "en principe" devrait être utilisé. Je ne sais pas encore si il y a avantage à mettre tous les no de série dans une table unique. À vous de voir.

J'ai essayé de vous donner accès à SQL Server, j'espère que ça va fonctionner. Ce n'est pas évidant. L'important dans un premier temps c'est d'être capable de vous logger même si vous ne pouvez rien modifier. Ce n'est pas évident tous faire dans en ligne de commande dans bash et Azure Data Studio.Je m'ennuie déjà de SSMS qui n'a pas et qui n'aura pas de version LINUX. Dommage :-( Mais vous à distance SSMS fonctionnera peu importe le server qui héberge SQL Server.

Msg 4405, Niveau 16, État 1, Ligne 26
La vue ou la fonction 'xxxxx' ne peut pas être mise à jour car la modification porte sur plusieurs tables de base.

[ordigil]

Branché avec LibreOffice à SQL Server 2017 version LINUX hébergé sur mon serveur openSuSE Leap 15.


Pièce jointe 442177
Pièce jointe 442180

[fsmrel]

Bonjour Ordigil,

Je ne sais pas encore si il y a avantage à mettre tous les no de série dans une table unique. À vous de voir.

Tout bien pesé, la sémantique l’emporte, la performance est en gros la même. Dans le cas de l’universalisation avec une base bien sollicitée en mise à jour, l’éparpillement des numéros de série est probablement préférable ; on va donc laisser les numéros de série dans leur lieu d’accueil naturel, les numéros de série des moteurs dans la table MOTEUR, etc. :

De même, donnons-nous de l’oxygène pour la partie Manufacturiers/Modèles, l’important étant le respect de la troisième forme normale. On retient donc la représentation suivante :

Je vais replonger dans la mise à niveau des CREATE TABLE, CREATE VIEW, CREATE TRIGGER et des jeux d’essai...

Je remets mon scaphandre.

[ordigil]

Bonjour fsmrel

Vous rendez intéressante le développement des bases de données.


On a un petit nouveau

Pièce jointe 442435

Bonjour Ordigil,



Tout bien pesé, la sémantique l’emporte, la performance est en gros la même. Dans le cas de l’universalisation avec une base bien sollicitée en mise à jour, l’éparpillement des numéros de série est probablement préférable ; on va donc laisser les numéros de série dans leur lieu d’accueil naturel, les numéros de série des moteurs dans la table MOTEUR, etc. :

De même, donnons-nous de l’oxygène pour la partie Manufacturiers/Modèles, l’important étant le respect de la troisième forme normale. On retient donc la représentation suivante :

Je vais replonger dans la mise à niveau des CREATE TABLE, CREATE VIEW, CREATE TRIGGER et des jeux d’essai...

Je remets mon scaphandre.

[fsmrel]

Bonjour Ordigil,

En haut de 'MANUFACTURER', ça serait utile d'avoir 'HEADQUARTERS'. Ainsi Daimler est le HeadQuarters de Freightliner, Detroit Diesel, Western Star. Navistar est le HeadQuarters de International, Anhui, MWM, Blue Diamond, NC2. Paccar est le HeadQuarters de Peterbilt, Kenworth, DAF.

J’avais oublié ces braves gens des sièges... On va leur faire une petite place

(Q1) Un manufacturier fait bien toujours référence à au moins et au plus un headquarters n’est-ce pas ?

(Q2) Souhaitez-vous considérer un headquarters comme un contact ?


J’ai exécuté les CREATE TABLE pour DZINDZIO_TRUCKS_MANAGEMENT_TEMP.

[ordigil]

Bonsoir fsmrel ;-)

(R1) Oui, le HEADQUARTERS c'est le haut de la pyramide

(R2) Oui car lorsque qu'un manufacturier ou un concessionnaire cause problème, on peut toujours s'adresser au headquarters.

Je ne suis plus du tout à jour dans la version ENGLISH :-( Je pense que je vais tout refaire :-(

[QUOTEfsmrel]
(Q1) Un manufacturier fait bien toujours référence à au moins et au plus un headquarters n’est-ce pas ?

(Q2) Souhaitez-vous considérer un headquarters comme un contact ?


J’ai exécuté les CREATE TABLE pour DZINDZIO_TRUCKS_MANAGEMENT_TEMP. [/QUOTE]

[ordigil]

C'est joli DZINDZIO_TRUCKS_MANAGEMENT_TEMP

Il n'y a que la Table AXLE_TYPE qui n'est pas relié à la Table AXLE

[ordigil]

Il y a des Tables qui ont disparu

[fsmrel]

Modèle mis à jour :

Les sièges sont des contacts

[ordigil]

C'est jolie

Toute la partie de MAINTENANCE_REPAIR a disparu

Modèle mis à jour :

Les sièges sont des contacts

[fsmrel]

Bonjour Ordigil,


Effectivement, la partie MAINTENANCE_REPAIR est passée à la trappe, mais normalement la situation est désormais rétablie.

[ordigil]

Pauvre fsmrel. Vous y mettez tellement d'énergie. Lorsqu'on regarde le diagramme, ça ressemble à une vraie base de données professionnelle.


J'ai hâte de m'en servir en version finale

Bonjour Ordigil,


Effectivement, la partie MAINTENANCE_REPAIR est passée à la trappe, mais normalement la situation est désormais rétablie.

[fsmrel]

Bonsoir Ordigil,


J’entame les vues concernant les sièges, les manufacturiers, etc.

 --------------------------------------------------
 -- Les sièges
 --------------------------------------------------

CREATE VIEW HEADQUARTERS_V (ContactName, CivicNumber, StreetName, City, Province, PostalCode
                          , PhoneNumber, WattLine, FaxNumber, CellNumber, WebSite, Interlocuteur)
AS
 SELECT ContactName, CivicNumber, StreetName, City, Province, PostalCode
      , PhoneNumber, WattLine, FaxNumber, CellNumber, WebSite, Interlocuteur 
 FROM   CONTACT AS x JOIN HEADQUARTERS as y ON x.ContactId = y.HeadquartersId
 ;
 
 --------------------------------------------------
 -- Les manufacturiers des camions
 --------------------------------------------------

CREATE VIEW TRUCK_MANUFACTURER_V (HeadQuartersName, ContactName, CivicNumber, StreetName, City, Province, PostalCode
                                , PhoneNumber, WattLine, FaxNumber, CellNumber, WebSite, Interlocuteur)
AS
 SELECT t.ContactName, x.ContactName, x.CivicNumber, x.StreetName, x.City, x.Province, x.PostalCode
      , x.PhoneNumber, x.WattLine, x.FaxNumber, x.CellNumber, x.WebSite, x.Interlocuteur  
 FROM   CONTACT AS x JOIN TRUCK_MANUFACTURER AS y ON x.ContactId  = y.TruckManufacturerId
                     JOIN HEADQUARTERS as z ON z.HeadquartersId = y.HeadquartersId
                     JOIN  CONTACT AS t ON t.ContactId = z.HeadquartersId 
 ;

Les triggers pour les inserts correspondants sont en cours de fabrication.

[ordigil]

J'ai perdu un grand bout avec la migration sur Linux :-( Je ne sais plus où je suis rendu LoL. Et en plus il y a des fonctionnalités limités dans la version Linux de SQL. Une parmi tant d'autres : Microsoft n'a pas jugé important de faire des audits sur les logins succeeded, seulement les logins failed…. Étrange, je suis beaucoup plus inquiet par les succeeced que par les failed…. Ça nous oblige à avoir un log seulement pour les succeeded… Mais ça semble bien fonctionner jusqu'à maintenant. Les temps de branchement et d'exécutions des requêtes sont plus rapides. Bon, il y a quelques petits bugs dans Azure Studio mais bons. Ça fonctionne très bien à partir d'un autre ordi avec SSMS.

Je ne sais même plus quelles vues on doit retravailler…. Presque toutes je pense LoL

Bonsoir Ordigil,


J’entame les vues concernant les sièges, les manufacturiers, etc.

 --------------------------------------------------
 -- Les sièges
 --------------------------------------------------

CREATE VIEW HEADQUARTERS_V (ContactName, CivicNumber, StreetName, City, Province, PostalCode
                          , PhoneNumber, WattLine, FaxNumber, CellNumber, WebSite, Interlocuteur)
AS
 SELECT ContactName, CivicNumber, StreetName, City, Province, PostalCode
      , PhoneNumber, WattLine, FaxNumber, CellNumber, WebSite, Interlocuteur 
 FROM   CONTACT AS x JOIN HEADQUARTERS as y ON x.ContactId = y.HeadquartersId
 ;
 
 --------------------------------------------------
 -- Les manufacturiers des camions
 --------------------------------------------------

CREATE VIEW TRUCK_MANUFACTURER_V (HeadQuartersName, ContactName, CivicNumber, StreetName, City, Province, PostalCode
                                , PhoneNumber, WattLine, FaxNumber, CellNumber, WebSite, Interlocuteur)
AS
 SELECT t.ContactName, x.ContactName, x.CivicNumber, x.StreetName, x.City, x.Province, x.PostalCode
      , x.PhoneNumber, x.WattLine, x.FaxNumber, x.CellNumber, x.WebSite, x.Interlocuteur  
 FROM   CONTACT AS x JOIN TRUCK_MANUFACTURER AS y ON x.ContactId  = y.TruckManufacturerId
                     JOIN HEADQUARTERS as z ON z.HeadquartersId = y.HeadquartersId
                     JOIN  CONTACT AS t ON t.ContactId = z.HeadquartersId 
 ;

Les triggers pour les inserts correspondants sont en cours de fabrication.

[ordigil]

Interlocuteur => FirstContactName