[Novice]Quel est le type de champs le mieux adapter

Bonjour,
Je ne sais pas trop quoi choisir pour 2 type de champs
L'un sera pour stoker des numéros de téléphone
par exemple 0227654324 ou +41227654321
(il doit conserver le 0 ou un +)

et aussi pour pour des numéro qui ont un "."
par exemple : 123.45.67


Aussi, j'ai un autre doute concernanrt les champ NULL ou pas.
Par exemple, dans mon formulaire j'ai des champs obligatoire. Donc le champs de ma base de donnée doit impérativement est NOT NULL?

Dans quel cas devrions-nous alors mettre un champs de la base de donnée NOT NULL?

Ton champs de téléphone est un varchar.

Pour la question du NULL, il est peut être plus simple ne pas gérer le cas NULL, tu te retrouveras donc avec une chaine vide si le champ n'est pas rempli.

NULL signifie "absence de valeur".
Une chaîne vide est une valeur dans une colonne textuelle et peut avoir une signification autre que "absence de valeur".

Si une colonne (et pas champ) textuelle de la table est NOT NULL, alors sa valeur par défaut sera probablement la chaîne vide (je ne sais pas si c'est automatique dans tous les SGBD).

Le fait qu'un champ de saisie dans un formulaire (et cette fois c'est bien un champ !) soit obligatoire ou non n'a rien à voir avec le NOT NULL d'une colonne de table.
Une colonne de table peut très bien autoriser le NULL parce que la conception de la BDD rend ce choix logique mais le champ de formulaire d'une des applications qui alimente la BDD peut rendre la saisie obligatoire parce que la logique applicative l'impose.

Ok merci pour vos réponses,
Donc en résumé, si je mets toutes mes colonnes en NULL, ca ne cause pas de problème.
Même en therme de sécurité?

Il y a des colonnes qui ne peuvent pas être mises à NULL : les clés primaires !

Un exemple simple pour comprendre...

Soit une table d'utilisateurs dans laquelle certaines colonnes peuvent être à NULL parce qu'on peut ignorer l'information et d'autres NOT NULL parce que ces informations sont obligatoires :

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE t_e_utilisateur_usr ( usr_id INTEGER NOT NULL PRIMARY KEY usr_nom_utilisateur VARCHAR(20) NOT NULL usr_nom VARCHAR(30) NOT NULL usr_prenom VARCHAR(30) NOT NULL usr_date_naissance DATE DEFAULT NULL usr_telephone VARCHAR(15) DEFAULT NULL )

---

Ha ben ok, c'est le raisonnement que j'ai eu.

J'ai des colonne que j'ai mis NOT NULL car le champs du formulaire est obligatoire. Mais en fait c'est alors plus une question de logique, si je peux dire ainsi.
non?

Je peux aussi très bien le mettre NULL, ca fonctionnera tout aussi bien
N'es-pas?

Avec la structure de la table que j'ai donnée tout à l'heure, si j'effectue cette requête :

Code:

---

1 2	INSERT INTO t_e_utilisateur_usr (usr_id, usr_nom_utilisateur, usr_nom, usr_prenom) VALUES (1, 'CinePhil', NULL, NULL)

---

Le SGBD retournera une erreur car j'essaie de mettre à NULL des colonnes NOT NULL. C'est ensuite à l'application de gérer cette erreur.

Si tu rends un champ de formulaire obligatoire, rien ne dit a priori que ce qui sera saisi sera conforme aux contraintes de la colonne de la BDD.
Exemple :
Nom d'utilisateur : CinePhil
Nom Leménager
Prénom : Philippe
Date de naissance : 24/17/1963

==> Je me suis trompé en saisissant le mois. De plus, la date n'est pas au format standard SQL 'aaaa-mm-jj' ; c'est au logiciel de formater la date correctement pour la SGBD.

Avec une telle date insérée, MySQL ne la comprendra pas et y mettre son format (idiot) de date nulle : '0000-00-00' !

Oui donc j'ai bien compris. J'ai eu ce message d'erreur.
Peut être que ma logique n'est pas bonne, mais alors je devrais mieux mettre toutes mes colonnes NULL pour éviter ce genre d'erreur.

Théoriquement, je le prévoirai dans l'application. Mais quand je créerai un compte pour un établissement, les champs (même les champs obligatoires) seront vide, car ca sera à l'établissement de les saisir. Puis après il ne sera pas possible que des colonne reste vide, car le formulaire obligera une siaise.

Pour le moment, j'agit directement dans la base de donnée, pour créer un compte, mais par la suite j'aurai une page web qui me permettra de créer des compte pour les établissement. C'est pourquoi je pense donc mettre toutes mes colonne NULL, puisque des colonnes seront vide à la création uniquement.

Mais en résumé, il faut mieux mettre une colonne NOT NULL, si le champs associé du formulaire est obligatoire. C'est bien ca?

Citation:

---

Envoyé par pierrot10

quand je créerai un compte pour un établissement, les champs (même les champs obligatoires) seront vide, car ca sera à l'établissement de les saisir.

---

Tu peux donner la structure de la table que tu as créée ?
Je suppose que tu dois avoir au minimum un identifiant clé primaire qui ne sera donc pas NULL mais auto-incrémenté par le SGBD. Et puisque tu parles de compte, peut-être que quand tu crées ce compte, tu affectes un numéro de compte à un établissement qui a un nom ? Donc au minimum, ces deux colonnes pourraient être NOT NULL puisque ce seraient les deux colonnes obligatoires pour la création d'un compte.

J'imagine une table avec cette structure :

Code:

---

1 2 3 4 5 6 7 8

CREATE TABLE t_e_compte_cpt ( cpt_id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY cpt_num_compte VARCHAR(5) NOT NULL cpt_nom_etablissement VARCHAR(50) NOT NULL cpt_adresse VARCHAR(100) DEFAULT NULL cpt_telephone_satndard VARCHAR(15) DEFAULT NULL )

---

Citation:

---

Puis après il ne sera pas possible que des colonne reste vide, car le formulaire obligera une saisie.

---

OK.

Mais en résumé, il faut mieux mettre une colonne NOT NULL, si le champs associé du formulaire est obligatoire. C'est bien ca?[/QUOTE]
Tu n'as pas forcément un seul formulaire qui va agir sur les données, tu as dit toi-même que tu créeras un formulaire pour la création du compte et un autre pour que l'établissement saisisse ses données. Même si dans ces deux formulaires, des champs de saisie seront obligatoires, toutes les colonnes de la table ne sont pas forcément NOT NULL, comme dans ma table ci-dessus.

Encore une fois, il faut bien distinguer les notions de contraintes sur les données, quelle que soit l'application qui utilise les données, et les contraintes applicatives, qui sont propres à chaque application, voire à chaque morceau d'application. Dans ton cas, les contraintes applicatives sont différentes lors de la création des comptes et lors de la saisie des infos par l'établissement.

Salut

Citation:

---

Théoriquement, je le prévoirai dans l'application. Mais quand je créerai un compte pour un établissement, les champs (même les champs obligatoires) seront vide, car ca sera à l'établissement de les saisir. Puis après il ne sera pas possible que des colonne reste vide, car le formulaire obligera une siaise.

---

On peu quand même considérer que créer un nouvel établissement sans nom est étrange, non ?
Comme ça, je dirais que ce serait à éviter, voir même à proscrire.
Imposer qu'un établissement ait un nom avant de créer l'enregistrement n'a rien d'anormal.

D'ailleurs, ceci aura pour effet,lors de la création d'un produit de proposer des établissements sans noms.
Du coup,pour éviter ça il faudra rajouter un couche à la requête pour exclure les sans noms.

Dans la réalité, on râle tous parce que l'EDF, ou autre service administratif nous fiche à la porte parce qu'il manque tel ou tel papier.
C'est quasi le même problème, il faut qu'il y ait toutes les info/pièces/papiers pour enregistrer le truc parce que le logiciel l'impose.

Mettre des NULL à tout bout de champ n'est pas forcément la meilleur chose à faire, car du coté applicatif il faudra aussi prendre en compte que toutes ces valeurs pourraient être NULL.

Ce problème est quasi le même que le type de donnée en Php, et on sait que Php à un typage très faible, et la conclusion est que ça débouche sur un manque de fiabilité de l'application.

Il ne faut pas non plus tomber dans l'excès, il y a des cas ou une valeur NULL sera la meilleur solution, ou le meilleur compromis.
Imposer une valeur par défaut c'est exactement la même chose, le faire systématiquement n'est pas forcément ce qu'il y a de mieux.


Toute est une question de logique, mais il ne faut pas perdre de vu que la Bdd est là pour se faciliter la tache du coté applicatif.
Si elle est mal conçue ou comporte des données illogiques ou pas fiables, c'est l'applicatif (Php) qui va trinquer, c'est une certitude.

Donc au final, je dirais oui, mettre NOT NULL, donc imposer une valeur (insertion ou mise à jour) pour ce cas là (un nom) me semble de loin le plus logique.
L'imposer aussi pour une adresse ou un N° de téléphone.

Mais ce cas de l'adresse ou/et N°, si on arrive à dire qu'il y aura des cas où des établissements n'auront jamais d'adresse ou/ N° de téléphone, au niveau conception on peu tout à fait envisager de créer une table pour ça, genre "etab_adresse" (couple id_adresse-id_etab) pour reporter l'adresse ici.
N'y sera enregistré que les établissements qui auront des adresses.
Lors d'une jointure sur ces 2 tables, la valeur de l'adresse sera NULL pour les établissements sans adresses.
Voilà une autre façon de faire qui débouche sensiblement sur la même chose, mais théoriquement plus propre si c'est vraiment le cas.
C'est un exemple. ;)

Oui alors avant de tout lire vos commentaires, il me doit de préciser un truc.

Je vais créer un compte pour des établissements (pour le moment manuellement, en ajoutant une ligne dans ma table)

Citation:

---

Je suppose que tu dois avoir au minimum un identifiant clé primaire qui ne sera donc pas NULL mais auto-incrémenté par le SGBD

---

Oui oui, dans tous les cas, j'ai un id_etablissement qui est NOT NULL et autoincréement

Citation:

---

On peu quand même considérer que créer un nouvel établissement sans nom est étrange, non ?

---

Oui en effet, il n'y auara pas de nom, car la colonne id_etablissement sera l'identifiant de mon compte. Concenrant le nom de l'établiseement, le "client" pourra entrer ce qu'il veut, par exemple : "Hotel du lac, Hotel du Lac S.A., Hotel et B&B du Lac" etc
Il s'authentifira avec un compte que j'aurai créé et un mot de passe que je lui aurai foruni. Puis il devra passer par la configuration de son compte, tel que la saisie du nom de son établissement, adresse etc....
Puis toutes les saisies rentrées, il pourrafaire usage.
Ceci, je verrai ca plus tard, mais je pense simplifier ceci en reprennant le données dans le formulaire d'inscription. Ce qui simplifira la tâche....

Néanmois, je suis aussi d'accord avec ca:

Citation:

---

Imposer qu'un établissement ait un nom avant de créer l'enregistrement n'a rien d'anormal.

---

Merci pour vos points de vue!

Citation:

---

Oui en effet, il n'y auara pas de nom, car la colonne id_etablissement sera l'identifiant de mon compte.

---

Là, je ne parviens pas à te suivre, ou il y eu erreur de frappe. :calim2:
Le champ "id_etablissement" est un ID d'établissement, pas un ID de compte.
Si tu mets une donnée qui n'a aucun rapport avec ce quelle prévoit, j'y mets des réserve sur la manière de faire.
Comme ça, celle ci serait un peu "donnée fourre tout".

Rien t'empêche de créer une table que je qualifierais de provisoire pour enregistrer les établissements non complets par exemple.
Ce seront ces infos dans cette table qui seront proposées au client, ce ne serait que lorsque que le client aura validé le formulaire, avec toutes les infos imposées où là ça sera enregistré dans la table officielle, (et l'enregistrement provisoire supprimé).
Ca peu paraitre lourd, mais ceci aura l'avantage de n'avoir aucun impacte sur la partie applicative et en plus de définir NOT NULL dans la table officielle, et surtout éviter des données illogiques ou sans rapports.

Enfin, c'est une idée. ;)

non en fait je me suis mal expliqué.

Il y a aura un id, un nom, une adresse, un tél etc.
Simplement l'id sera incrémeté et unique a chaque création de compte.
La colonne nom sera vide, mais quand l'établissement lancera l'application pour la premier fois, il devra remplir les formulaires, notament celui des données de son établissement (dont le nom). C'est pourquoi, ce champs existe mais est vide jusqu'a la démarche de l'établissmeent.

Ce que je voulais dire, c'est qu'il sera l'unique identifiant de l'établissement côté applicatif. Cepend, le nom de l'établissement rera pour identifier l'établissement sur les pages...

Ok ;)

Je trouve ça un peu dommage de cette valeur NULL par défaut alors que la logique veut quelle soit imposée, quelle existe.
M'enfin, ce n'est pas de la plus haute importance non plus, on est d'accord. ;)

Mais faudra faire gaffe à ne pas trop généraliser ce genre de truc, car ça oblige normalement à rajouter des sur-couches de code Php, du moins, si on veut un truc assez stricte.

Oui je tiens compte de ta remarque, et par principe, je vais utiliser le plus possible de NOT NULL
Merci