Purge partielle d’une table

Code:

---

1 2	R001C: l'association à un seul unique identifiant (Id_client et code_client dans le schéma post #90) quelle est la différence entre Id_client et code_client ? (y a pas un doublon ?)

---

Id_client = clé primaire numérique en auto incrément le besoin est utile pour la prochaine (N+1),
Code_client ou code_deposant = code à deux lettre que l'on attribut au déposant ou client si tu préfère. (à force je m'embrouille entre le nom de la colonne et la dénomination dans les règles de gestion); Dans la table déposant c'est "code_deposant"

Code:

---

1 2	R004c : un type peut correspondre à plusieurs documents. pas clair !

---

D’après les règles établie par Escartefigue, un document représente un type d'article donc soit : Livres, ou DVD, ou CD, ou Vynil. De ce fait la personne peux déposer plusieurs livres, ou plusieurs DVd, et idem pour les autre catégorie d'article (documents) Sachant que les articles ne sont pas dénombré individuellement mas en quantité pour chaque catégories dans la Bdd.

Code:

---

N+1, c'est quoi ?

---

on vas dire aujourd'hui Novembre 2023 >>> N+ = Novembre 2024.

Pièce jointe 646413

À propos des identifiants et des codes.


Identifiant : attribut ou groupe d'attributs permettant de reconnaitre de façon certaine une seule occurrence d'entité.
Au stade SQL, l'identifiant devient la clef primaire (PK) de la table
En général, on choisit comme identifiant une colonne technique dont la valeur est attribuée par le SGBD (identity, auto_increment, serial... selon le SGBD)
L'intérêt d'un identifiant technique est qu'il est à la fois concis, donc performant et surtout stable car dénué de sens fonctionnel. La stabilité est un critère important à cause de la propagation des PK dans les tables liées.
Un identifiant est obligatoire irreductible, unique et non nullable.

Code : attribut permettant d'associer un nom très court à un libellé. Il a un intérêt mnémonique et pratique : plus facile à mémoriser qu'un libellé et plus pratique à l'usage.
Comme un identifiant, un code doit être unique, mais il peut éventuellement être "nullable"

On s'abstient souvent de retenir le code comme identifiant, en particulier si le code est issu d'une nomenclature externe.
En effet, une nomenclature externe peut changer, ce qui impacterait lourdement les tables liées si l'on avait choisi le code comme PK.
Par exemple, les codes département ont changé à plusieurs reprise, lors de l'éclatement de la Seine et Oise en 1968 ou du découpage de la Corse en 1975.
Il en va de même avec les codes communes, à cause des fusions.

C'est la raison pour laquelle la coexistence d'un code et d'un identifiant dans une même table ne sont pas forcément une redondance.

Citation:

---

Envoyé par escartefigue

À propos des identifiants et des codes.


Identifiant : attribut ou groupe d'attributs permettant de reconnaitre de façon certaine une seule occurrence d'entité.
Au stade SQL, l'identifiant devient la clef primaire (PK) de la table.

---

Qu'entends tu par PK ??

Citation:

---

Envoyé par escartefigue

Comme un identifiant, un code doit être unique, mais il peut éventuellement être "nullable".

---

La pour mon besoin il ne peux pas et ne doit pas être NULL, de ce fait UNIQUE.

Citation:

---

Envoyé par Djockey

Qu'entends tu par PK ??

---

PK = Primary Key (EN) = Clé Primaire (FR)

Merci, je cherchais plus compliqué.

Citation:

---

Envoyé par Djockey

La pour mon besoin il ne peux pas et ne doit pas être NULL, de ce fait UNIQUE.

---

NULL et UNIQUE ne sont pas contradictoires : une colonne nullable peut tout à fait faire l'objet d'une contrainte UNIQUE.
Et pour cause : NULL n'est pas une valeur, mais un marqueur d'absence de valeur, ainsi NULL et NULL donne "faux"


Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

with t1(C1, C2) as (select 1, null union all select 1, 1 union all select null, 1 union all select null, null ) select C1 , C2 , case when C1=C2 then 'égal' else 'différent' end as XX from T1

---

Résultat :

Pièce jointe 646512

Exemple réservé aux spécialistes...dont je ne fais pas partie vu que je ne le comprends pas (pourtant testé : il marche).

C'est simple pourtant si l'on comprend que "null" n'est pas une valeur, mais une absence de valeur, une inconnue.

Ce faisant, null ne saurait être égal à null ni à quoi que soit, d'où le tableau de vérité particulier dans le cas de marqueurs "null".

C'est pour cette raison du reste qu'en SQL, on ne dit pas MA_COLONNE = NULL mais MA_COLONNE IS NULL.

Exception notable toutefois : Oracle confond allègrement null et chaîne de caractères vide :aie:, c'est une véritable hérésie ! Heureusement, les autres SGBD font bien la distinction.

Citation:

---

Envoyé par escartefigue

NULL et UNIQUE ne sont pas contradictoires : une colonne nullable peut tout à fait faire l'objet d'une contrainte UNIQUE.
Et pour cause : NULL n'est pas une valeur, mais un marqueur d'absence de valeur, ainsi NULL et NULL donne "faux"

---

bien compris, surtout avec l'exemple. Je retiens.

Bon alors du coup mise a wamp, 3.3.0 avec php 8, suppression des "get_magic_quotes_gpc" et refonte des scripts concernant la gestion des déposant et du dépôt des différent article " catégories"

Merci a tous.

Je ne te lis que aujourd'hui : du coup, tu continues avec la même structure de bdd, même si elle est pas terrible...

Ben disons question facilité et moins prise de tête pour moi avec mes humbles connaissance