Reprise du message précédent :
en fait l'utilité ca va etre de generer des factures, des bons de commande, des codes barres, qrcodes, et ecrire du texte à la verticale, ...
 
C'est vrai que l'avantage à wkhtml, c'est que je fais tout en html/css, et roule, mais ca risque d'etre moins cadré (si je bosse avec fpdf, c'est sur un format defini (type A4), et je place mes infos au mm pres.
 
En html, comment definir une "page" A4, et placer tout parfaitement, comme je le ferais avec fpdf ? J'ai peur que le rendu soit moins bon

teste en vrai, tu sera surpris : http://fr.selfhtml.org/css/proprietes/printlayouts.htm
 
en plus le cout des test est ridicule : monter une page html . Alors qu'avec fpdf, dès que tu veux faire  des choses unpeu plus riches ( un paragraphe de texte avec des zones variables )  ça devient lour

Sinon, il y a aussi la possibilité de générer du latex, et de le transformer en PDF ...

Putain mais Doctrine, quel truc de merde  

Ben quel est le problème, c'est toi qui ne sait pas l'utiliser

Je me souviendrai d'aller voir leur bugtracker histoire de vérifier que ce qui se trouve indiqué dans leur doc n'est pas "New Feature / In Progress" la prochaine fois.

Et maintenant ça : https://groups.google.com/forum/#!m [...] uQyhbb6dAJ

Saloperie écrite par des crétins de mecs qui ne connaissent que le java et ont peur d'utiliser la puissance d'une bdd relationnelle.

donc tu utilises des clés naturelles plutot que des id en auto incrément ?  
 

débat sans fin incoming.

Les deux, suivant les tables. Et même celles avec des auto-increment proviennent d'un import d'une ancienne version de la base bien dégueulasse, elle même provenant en grosse partie de données externes contenant des "ID non stable" d'après le provider.

NOT THAT SHIT AGAIN§§§§§

ceci dit, au dela de considération ethiques , doctrine et symfony  fonctionne bien mieux sans clé naturelles

 
Chais pas si ça peut t'aider, mais ici j'ai eu un pb similaire avec l'orm de Django qui ne supporte que des id et qu'on devait faire marcher avec des tables existantes ayant des clefs naturelles (ou pas de clef du tout, mais bon...), ces tables étant en même temps utilisées par du code hors-Django (donc pas de conversion sans retour possible).  
 
Résultat la "vrai" clef naturelle est définie dans Django comme étant un groupe de champs uniques, et une colonne auto-increment a été ajoutée à la db, utilisée par Django comme pk et ignorée par le code existant.

CQFD, les ORM c'est de la merde.
 
[/remet une pièce]

 
Est-ce qu'il y existe un seul type d'application qui fonctionne mieux avec des clés naturelles plutôt que des IDs auto-incrémentés ? Les clés naturelles, c'est de la branlette de théoriciens en base de données, mais en pratique, ça ne fait que compliquer les choses.  

Les clés auto-incrémentées c'est pour les mecs qui sont trop mauvais pour faire les choses proprement.

...t'as vu, moi aussi je peux le faire!

une clé naturelle, ca serait genre un table des communes de france, avec le code INSEE en clé ? Cad pas un ID géré par le SGBD ?

Par exemple.

Ou, soyons fous, une clé composée par plusieurs champs.

oh oui, c'est complètement barjot!

Nous on met id auto_inc en PK + la clé naturelle en index unique.

Et pour ma culture personnelle, dans l'exemple de la table "commune", quel est l’intérêt d'avoir une clé primaire "supplémentaire" en auto increment, en plus de la colonne insee avec un index + unique, vu que dans les faits on jointera et recherchera sur cette colonne ?

moi je suis en train de jouer avec des UID, parce que ça devient le bordel les auto-increment quand ton système est distribué entre 3 bases de données (dont une amazon)

Parce-que sinon les ORM boudent et t'es obligé de leur expliquer comment travailler. Conventions de flemmards, quoi.

 
Dans les faits, on fera toutes les jointures sur la clé auto-incrémentée. Les avantages :
- on est sûr qu'elle ne changera jamais (surement le point le plus important, une clé primaire qui change, c'est super merdique)
- on a parfois un léger gain de perf (parce que toutes les jointures se feront sur des entiers) et en espace disque
- ça permet d'avoir une convention de nommage cohérente (par exemple, la clé primaire s'appelle toujours "id" )
- ça facilite le travail avec certains outils, les ORMs en particulier

Il y a un code insee par arrondissement
donc plein pour paris/lyon/lille

faire des jointures sur des entiers, c'est pas mal aussi, plutôt qu'un varchar a rallonge ( le premier qui stockes les code insee en int passe par la fenetre )  

 
Une clé naturelle qui peut changer ça n'existe pas non plus. Si ça change, ce n'est pas une clé.
 

 
C'est sûr que tu gagnes énormément de place en rajoutant une colonne sans information pertinente à chaque table.
 

 
Oh oui, 430 "id" dans la table, ça aide à la compréhension bien plus que "num_insee".
 

 
Le seul point valide. On appelle ça de la flemme, habituellement.

A noter que je suis plutôt partisan des clé naturelles, mais si elles apportent un plus.
si la conséquence c'est devoir se priver de toute une gamme d'outil, je ne suis pas sûr que le jeu en vaille la chandelle.

Modifier la structure de la base pour faire plaisir à un outil me parait encore moins valable...mais on a déjà eu ce genre de discussions...

oui  
ceci dit, regarde mon post un peu au dessus : le code insee n'est pas forcement une bonne clé naturelle
 
Idem pour les agents, le numéro de sécu n'est pas forcement utile (on a des doublons chez nous : numéros mal  saisis par exemple ) , tout ce qui est code temporelle est sujet aux simultanéités et au changement d'heure

La flemme est la qualité première d'un programmeur  

Hello!
 
Petite question, dans ma boite on est 6 devs maintenant à intervernir sur environ 220 sites. Mais on a gardé la même architecture qu'au début (1 dev avec Dreamweaver). Seulement voilà, Dreamweaver c'est de la daube en barre. Moi j'utilise Coda sous Mac qui est mieux et qui supporte le collaboratif mais je suis le seul sous mac. Donc il nous faudrait un logiciel qui tourne sous Mac/Win, qui supporte le travail collaboratif (genre qui "locke" un site pendant que quelque'un bosse dessus), où on puisse avoir une trace de qui a fait quoi... et qui soit assez agréable à utiliser. CJe suis en train de tester PHPStorm, il a l'air pas mal, surtout depuis la version 3... Vous utilisez quoi vous ?

 
Je vois pas le problème d'avoir un code par établissement?
 

Avec une clé sur le numéro de sécu tu n'aurais pas de doublons.

 
Faux. Les seules contraintes sur une clé primaire, c'est qu'elle soit requise et unique. L'invariabilité n'est pas obligatoire (et en pratique, c'est rarement possible de la garantir avec une clé naturelle). Et le fait qu'on puisse mettre un "ON UPDATE CASCADE" sur les clés étrangères indique bien que c'est un cas qui doit arriver...
 
 

 
Tu gagnes de la place à chaque fois que ton objet est lié à un autre.
 

 
C'est surtout que ça t'évite d'avoir à aller rechercher le nom du champs qui sert de clé à chaque fois que tu veux faire une jointure.
 
 

 
Ou pas  
 

 
Avec un index unique non plus.

 
1- Quand tu feras tes requetes tu seras forcément contraint de définir une clé primaire, même si elle est composée. Par exemple num insee+nom de ville. Autant la définir en dur dès le début.
2- Pour les numéros insee en double, ça prouve l'utilité d'une clé primaire: éviter ce genre de choses.

SVN ?
Vous ne bossez pas direct sur des sites en production quand même ?

 
   Rien de tout ça, on fait nos sites web a la mano, comme des hommes.

La commune lyon apparait 10 fois . Pourtant qu'il n'y a bien qu'une ville composée d'arrondissement
On a des numéros de sécu identiques ( agent en cours de recrutement par exemple )  

1/ ce qui s'appelle une contrainte d'unicité , donc une clé unique, pas une primaire  
2/ on est d'accord

Un concepteur qui choisit comme clé un champ dont la valeur peut changer ne mérite que la pendaison par les couilles.

Tout dépend de la nature de ta clé naturelle.

Si on appelle ça "naturelle" c'est parce-qu'on sait naturellement que ce champ est la clé, à la base.

 
Chaque arrondissement a son maire, ils sont équivalents à des communes. Ce n'est pas un découpage anodin.
 

 
WTF?

 
Une clé primaire est unique, et là je parlais d'aggréger plusieus champs, donc bien une PK.