Difficile à trancher :/
Tout dépend de la complexité du modèle de données.
Par exemple, dans le métier de la billetterie, la complexité est suffisante pour justifier ce genre de taille.
Si je ne m'abuse, scinder une table fait perdre énormément de perfs, potentiellement.

Les ennuis commun posée => combo pluriel - masculin - féminin ! Au hasard, y'aura forcément un mot juste sur les trois...

Il aurait dû écrire "les ennui commune posées", aucun mot de juste /o/

Si c'est pour faire des tables en dehors avec des relations 1-1, il est préférable d'avoir une table avec plus de colonnes.
Sachant que le "select *" c'est mal...

Pas tout à fait. "posées" serait bien accordé avec "Les". Je tenterai plutôt l'infinitif personnellement, histoire de bien marquer le coup :
"Les ennui commune poser." La ces baud. La sa sans le viole gramatiqual.

Perso, je cherche également une bonne raison de passer sur plusieurs tables. Si c'est en effet pour faire des relations 1-1... Maintenant, chuis pas expert SGBD, hein, y'a peut-être un gros gain de temps en fractionnant en plusieurs tables, allons savoir.
J'aimerai d'ailleurs avoir l'avis de quelqu'un de calé en la matière.

Idem, j'aurais du mal à trouver des besoins justifiant cette horreur, mais sans plus de détails on ne peut se permettre de dire que cela n'en fait pas partie.
Tu pourrais expliciter le besoin du métier de la billetterie? Juste par curiosité :)

Je suis pas dans le département qui fait ça dans ma boîte, mais j'ai un peu discuté avec les gens et vu les schémas du DB model, et l'idée, c'est qu'une place pour un spectacle ou un événement, c'est loin d'être simple. Ça peut être acheté par une personne A, pour une personne B, livrée à l'adresse d'une personne C, on peut y accorcher une liste de services optionnels, il peut y avoir des changements sur la réservation par l'utilisateur, des changements dans l'organisation de l'événement, ... Et en plus il y a des contraintes de performances très tendues (vente de billets pour concerts/festivals/...). Du coup le modèle de DB doit pouvoir répondre à tout ça... Et ça fait parfois des tables monstrueuses :)

Au secours, j'ai les yeux qui saigne !
Non gnome nazi, range ce lance-bescherelle-au-napalm !

Ils "saigne" tellement que tu ne vois même plus tes propres erreurs ! :P

Calé ou pas (j'ai jamais vraiment bossé dessus, mais j'avais de supers notes en cours de modélisation -SGBD à la fac :P), on ne peut rien dire sans savoir ce qu'il y a dans la base en question. Le principe de la modélisation, c'est de s'adapter au mieux à chaque situation. Là, on ne sait rien du contexte...

... du coup, dire qu'il s'agit d'un PEBKAC parce qu'il y a 150 colonnes sur une table sans rien préciser d'autre, c'est un peu abuser, non ?

Voilà. C'est pour ça qu'il y a peu de votes et que ceux qu'il y a sont plutôt partagés...

Oui.
Je ne suis loin d'être calé sur le sujet, mais la différence de perf entre une table avec beaucoup de colonnes et plein de petites tables avec une relation 1-1 vas dépendre de la version du SGBD.
Et suivant le nombre d'accès qui sont fait dessus et le nombre de lignes, la différence a des chances d'être négligeable au final.
Surtout si on doit lire toutes les colonnes à chaque fois.

Dans un CRM c'est tout à fait classique. On manque de contexte là, si c'est un SGBD SQL classique, il est orienté ligne, on a stricto-sensu besoin de faire une nouvelle table uniquement pour un nouvel "objet", sinon le seul résultat c'est d'avoir des jointures inutiles, rien de plus imbitable et sous performant qu'un sgbd avec des foutraques de tables liées en 1-1

Pas mieux. Sans plus de détails il est difficile de dire s'il s'agit ou non d'un PEBKAC.
Dans le doute je vote "CTLP" pour la description incomplète.

Ne pas scinder ta table peut te coûter très cher en perfs aussi.
Au-dessus de vingt, il faut y penser, surtout si certaines données sont plus rarement utilisées ou sémantiquement isolées.
Il ne faut pas se buter à certains principes, il faut voir ce qui serait le mieux pour l'utilisation d'une telle base de données.

Tu t'abuses totalement, ou tu utilises encore SQLAnywhere version 1.
Une table normée de 150 colonnes, c'est théoriquement extrêmement rare. Tellement rare, même, que ça n'arrive jamais en pratique.
Par contre, des développeurs qu'on devrait pendre haut et court pour ne pas avoir lu Boyce-Codd, compris les formes normales, et au passage réinventer dans leur code un micro-moteur de base de donnée, ça, ça existe. J'en croise régulièrement, et j'en vois ici encore quelques-uns.

Répétez après moi: une RDBMS n'est PAS un fichier plat.

Et si ça vous saoûle de faire des schémas propres, ayez au moins la décence d'utiliser les outils appropriés: bases réparties orientées Document, BigTable ou Graph. Nom de nom, vous n'avez aucune excuse: les outils existent, ils sont gratuits, et c'est votre METIER, bordel!

Croyez-moi: le jour où on foutra à la porte des développeurs pour ce genre de bêtise aussi souvent qu'on fout à la porte un ouvrier qui saccage le boulot, le Pôle emploi ne manquera pas de candidats.

Hmmm. C'était le coup de gueule du soir de votre architecte, merci de votre attention.

Je le mets là, parce que visiblement, il y a un nid: http://lmgtfy.com/?q=Forme+normale

Normalité et norme ne veulent pas dire que cela va régir TOUS les cas.

En l'occurrence, je suis pas sur le projet dont je parle. J'ai juste des collègues qui bossent dans le milieu et qui sont bien meilleurs que moi sur la question. J'ai sans doute mal expliqué, mais le fait est qu'ils ont des tables avec plein de colonnes et des perfs excellentes.

Je veux bien croire qu'il y ait plein de noobs qui font des tables n'importe comment. Comme expliqué plus haut, je suis loin d'être spécialiste. J'ai juste des collègues dont c'est le métier et qui ont créé une solution de billetterie qui a fait ses preuves en termes de perf (avec pics de charge et tout) chez un paquet ce clients, et qu'ils ont des tables monstrueuses. Mais j'ai sans doute mal expliqué pourquoi, vu que moi-même je ne connais pas particulièrement.

Je ne vois pas le rapport. Rien n'empêche d'avoir 150 colonnes, même en BCNF...

Tu connais beaucoup d'objets sémantiques théoriques justifiant 150 attributs conformes ne serait-ce qu'à la 3ème forme? Et si on passe à la pratique, je serais très, très interessé à voir un cas où, hors dénormalisation énorme - donc typiquement, hors de la constitution d'un datamart - ce genre de table est normé.

Normalité, norme et normalisation d'un schéma de données sont 3 choses différentes.

La forme normale est simplement l'expression en language courant des simplifications prises avec la théorie des ensembles sur laquelle s'appuie les implémentation des moteurs de RDBMS.
Dis autrement: tu peux enfoncer une vis avec un marteau, c'est très rapide, mais le résultat sera ni propre, ni fiable dans le temps.

Tout développeur devant interagir avec une RDBMS - et a fortiori, avec une base récente type NoSQL/distribué - devrait a minima revoir rapidement l'historique du stockage des données et le pourquoi des choix fait par chaque génération. En informatique comme de manière plus générale, ceux qui ne connaissent pas l'histoire sont condamnés à en commettre à nouveau les erreurs.

Moi non, mais là comme j'ai répété plusieurs fois, on n'a pas le contexte. Ce n'est pas parce que ça semble hallucinant que ça n'est pas possible.

Pas de contexte. Par ex, dans un ERP c'est pas choquant, ça peux aller à plus de 200 champs sans problèmes.