Discussion :

[alcsi]

Bonjour,
Question bête, pour un cas où j'ai de tout petits fichiers, destinés à le rester (exemple : "SALLES", il y a 10 salles chez nous, chacune avec un ID pour faire des réservations... Les ID n'iront jamais au-delà de 200 ou 300 même en imaginant des dizaines de déménagements, et en considérant qu'on crée de nouvelles ID à chaque fois par souci d'archivage de données...).

Je me disais donc, est-ce que je peux simplement utiliser un autre format d'entier ?
(Je constate à l'instant qu'il n'y a le choix que de 4 ou 8... mais la question subsiste).

Est-ce que certains l'ont fait, par économie de données p.ex. et ont eu des soucis qu'ils auraient pu éviter ?

Merci d'avance pour vos lumières, retours... !

[Voroltinquo]

Bonjour,
Tu peux même te passer de l'IDauto, le numéro de salle ou son nom est un bon candidat pour devenir PK. Tout cela se décide lors de l'analyse conceptuelle.
La PK sur 8 n'est utile que pour la réplication de serveur.

[frenchsting]

Bonjour,

+1 à Voroltinquo.

Si tu veux un id numérique, tu peux aussi utiliser un entier d'un autre format genre un entier sans signe sur un octet (255 max). Lire le dernier idSalle de ta table et "faire +1" dans le code au moment de l'ajout de ta salle en base.

[Voroltinquo]

Lire le dernier idSalle de ta table et "faire +1" dans le code au moment de l'ajout de ta salle en base.

Ou plus simplement le n° qui est inscrit sur la porte.
La PK n'a pas besoin d'être numérique. Tu peux avoir une salle A1.
Dans une table "Formule d'appel", la PK peut très bien être la formule elle même.

Définition d'un identifiant dans un MCD
Un identifiant est un attribut d'entité ou un ensemble d'attributs d'entité, dont les valeurs identifient de manière unique chaque occurrence de l'entité. L'identifiant dans le MCD correspond à la clé primaire ou à la clé alternative dans le MPD.

Chaque entité doit comporter au moins un identifiant. Si une entité n'a qu'un seul identifiant, alors ce dernier est désigné par défaut identifiant primaire de l'entité. C'est l'identifiant principal d'une entité.

Si tu envisage un déménagement, la PK peut être la concaténation du nom du lieu et du n° de salle

[frenchsting]

Je parlais du cas, où il souhait "absolument" un id numérique en plus du n° de salle.

[alcsi]

Merci pour toutes ces infos !!

Je vais faire des essais dans ce sens alors !

[tatayo]

Bonjour,

Ou plus simplement le n° qui est inscrit sur la porte.
La PK n'a pas besoin d'être numérique. Tu peux avoir une salle A1.
Dans une table "Formule d'appel", la PK peut très bien être la formule elle même.

Si tu envisage un déménagement, la PK peut être la concaténation du nom du lieu et du n° de salle

Et le jour ou un plan de renommage des salles est décidé, tu as comme un petit soucis… en plus de modifier la valeur des PK, il faut reporter cette modification dans les FK liées.

Une PK doit être asémantique, un peu plus d'infos là.

Tatayo.

[kunnskap]

Je plussoie tatayo, fortement.

Il n'est pas bon, pour l'avoir vu plusieurs fois, d'utiliser des valeurs accessibles à l'utilisateur en tant que PK d'une table. La PK ne doit pas être en lien avec le métier, ni être accessible à l'utilisateur, et pour des raisons de performances le fait qu'elle soit numérique est beaucoup mieux.

8 octets c'est obligatoire si un jour la base doit être utilisée dans le cadre d'une réplication serveur sur HF et qui peut prévoir à l'instant t si un jour, la base aura à être utilisée dans ce cadre? Le problème c'est que si ça doit être le cas par la suite, cela donne des changements qui peuvent être très lourds.

La recommandation que je fais est de toujours avoir une PK dans la table. A la limite, dans quelques cas vous ne l'utiliserez pas, mais mieux vaut l'avoir et ne pas en avoir besoin que l'inverse.

[frenchsting]

La recommandation que je fais est de toujours avoir une PK dans la table. A la limite, dans quelques cas vous ne l'utiliserez pas, mais mieux vaut l'avoir et ne pas en avoir besoin que l'inverse.

Je te plussoie également par rapport à ton plussoiement et cette partie que je trouve tellement évidente que ça devrait couler de source !
D'autant plus qu'on n'a plus le souci de devoir calculer à l'octet près le dimensionnement des BDD...

[kunnskap]

Je te plussoie également par rapport à ton plussoiement et cette partie que je trouve tellement évidente que ça devrait couler de source !
D'autant plus qu'on n'a plus le souci de devoir calculer à l'octet près le dimensionnement des BDD...

Merci pour ton re-plussoiement (diantre, j'ignore si les arcanes de la langue française me pardonneront)

Effectivement dans une logique d'espace très contraint ça s'entends, mais sinon si il utilise 8 octets au lieu de 4 pour 10 enregistrements, bon, 40 octets de plus on va pas déclencher l'alarme
Parce qu'à côté de ça, des moulinettes de changement en masses de FK à travers la base, je m'en suis flanqué plusieurs...et quand on veut apporter le concept ORM dans une base sans PK dans les tables, c'est quand même vachement moins pratique. Ca freine l'évolutivité et ça entache les perfs.

[frenchsting]

Côtés arcanes, je pense que c'est quand même mieux que le français moderne (checker, matcher, forwarder, deadline et autres néo anglicismes pour ne pas dire... insultes langagières)

Oui, sauf rares exceptions, mettre un id auto, c'est vache de mieux (...pas taper l'arcane)...

Et, oui 40 octets de plus, c'est une luxe que l'on peut facilement s'offrir. On n'est plus sur des disquettes de 360ko...

[serendib]

Côtés arcanes, je pense que c'est quand même mieux que le français moderne (checker, matcher, forwarder, deadline et autres néo anglicismes pour ne pas dire... insultes langagières)

Oui, sauf rares exceptions, mettre un id auto, c'est vache de mieux (...pas taper l'arcane)...

En fait l'id auto, en fait, c'est trop bien du coup, en fait.
Y'en a qui l'utilise pas ? j'hallucine !

Du coup je te plussoie.

[frenchsting]

En fait l'id auto, en fait, c'est trop bien du coup, en fait.
Y'en a qui l'utilise pas ? j'hallucine !

Du coup je te plussoie.

J'ai souvenir d'une table en particulier ou cet idauto n'était pas du tout nécessaire. Les enregistrements n'étaient pas "indépendants". En (très) gros, la table ressemblait à ça :Roue(TypeVéhicule, Position,...)On avait qq chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Voiture, AVG,... / Voiture, AVD,... / Voiture, ARG,... / Voiture, ARD,... / 
Camionnette, AVG,... / Camionnette, AVD,... / Camionnette, ARG,... / Camionnette, AIG,... / Camionnette, ARD,... / Camionnette, AID,... /
...
(Pour la camionnette, on a les roues intérieures)

Aucun intérêt d'avoir un idauto dans le sens, ou on ne lit jamais un seul enregistrement mais tous les enregistrements d'un type de véhicule. De plus, la table était très limitée en types de véhicules et plutôt figée dans le marbre...

[serendib]

Bonsoir frenchsting,

Mon intervention c'était juste un peu d'humour pour me moquer des tics de langage.
(comme toi - et moi d'ailleurs - des anglicismes)

Ceci dit et plus sérieusement il peut arriver que l'idauto soit vraiment totalement inutile.

Il existe aussi des poissons volants, mais ils ne constituent pas la majorité du genre !
Michel Audiard.

[frenchsting]

Hello serendib,

J'avais bien compris que tu faisais de l'humour.

Je voulais juste mettre un exemple de table sans idauto (ni clé primaire) parce qu'une ampoule s'était allumée dans mon esprit.
Heureux soient les fêlés, car ils laisseront passer la lumière. Michel Audiard