On te dit que c'est tres utile quand tu utilises une majorite de champs, y'a pas ecrit : * FTW dans toutes les circonstances.

Pour la maintenance et les performances c'est à éviter les SELECT *

lolilolzor, faire passer 500 caractères de plus (ça fait une belle requête, déjà) sur du réseau local ça coûte quoi?
Je plussoie le "toujours énumérer les champs à sélectionner".

2eme post de ma journée et 2eme    
c'est pas la poignée de caractère de plus qui va te faire économiser quoi que ce soit niveau performance ( sachant qu'a ce niveau , il y a plus de latence réseau que de temps de transfert )  et ca evite un transfert largement plus important dans l'autre sens
 
par contre, dans une requete un peu lourde, ne pas savoir de quelle table vient un champ c'est une perte de temps
 
De tout manière, pour utiliser tes 15 000 champs , il faut bien, a un moment ou un autre que tu les écrives, donc le faire une fois de plus me semble pas choquant

Le temps ridicule que tu gagnes sur le réseau tu le perds de toute manière largement coté base de données quand elle décode ton * en une vraie liste de champs

ça coute toujours un peu, et vue la quantité de temps perdue pour envoyer quelques caractères de plus sur un réseau local, je vois ça au moins équivalent.

non * c'est mal dans toutes les circonstances. Au mieux tu as le même résultat qu'en énumérant les champs.

Je viens de te dire que c'était pas nécessairement le cas bordel
 
merci pour cet exemple d'échec collégial, c'est marrant le matin en commençant la journée

merci pour cet exemple d'échec collégial, c'est marrant le matin en commençant la journée

Et ton avis fait foi ?

Merci pour cette affirmation sans aucune justification qui fait vachement avancer le débat.

ben c'est du masklinn , quoi

Non, c'est pour ça que j'ai donné la source juste avant comme ça tu peux vérifier: Keynote Djangocon 2008 Why I Hate Django par Cal Henderson, chief software architect de Flickr, auteur de Building Scalable Web Sites, et pas mal d'autres trucs. Et si t'es pas d'accord, tu peux même aller lui dire qu'il connait pas son boulot et que c'est un gros con

Non, c'est pour ça que j'ai donné la source juste avant comme ça tu peux vérifier: Keynote Djangocon 2008 Why I Hate Django par Cal Henderson, chief software architect de Flickr, auteur de Building Scalable Web Sites, et pas mal d'autres trucs. Et si t'es pas d'accord, tu peux même aller lui dire qu'il connait pas son boulot et que c'est un gros con

Enfin des gars qui font référence dans le domaine des SGBD et qui disent que les SELECT * faut éviter je peux t'en sortir des camions aussi

Ptin mais vive la team d'attardés

Et des gars qui donnent des raisons et en ont fait l'expérience en prod sur un système de taille t'en as aussi?

 
Non mais attends, t'as vu la gueule des arguments que tu sors aussi ? Entre les arguments d'autorité et le risible "ah mais * ça fait moins de bytes sur le réseau" faut quand même s'accrocher pour donner du crédit à ton avis sur ce coup là hein

 
Non mais attends, t'as vu la gueule des arguments que tu sors aussi ? Entre les arguments d'autorité et le risible "ah mais * ça fait moins de bytes sur le réseau" faut quand même s'accrocher pour donner du crédit à ton avis sur ce coup là hein

Non, c'est pour ça que j'ai donné la source juste avant comme ça tu peux vérifier: Keynote Djangocon 2008 Why I Hate Django par Cal Henderson, chief software architect de Flickr, auteur de Building Scalable Web Sites, et pas mal d'autres trucs. Et si t'es pas d'accord, tu peux même aller lui dire qu'il connait pas son boulot et que c'est un gros con

Ptin mais vive la team d'attardés

d'ailleurs on devrait tous coder en C quand on apprend, histoire de vraiment savoir ce qui se passe pour comprendre plus tard l'intérêt d'un langage de haut niveau et savoir ce que ça apporte

se faire traiter d'attardé par un type qui dit que l'étoile c'est mieux qu'une liste de champs parce que ça coute moins cher en trafic réseau c'est quand même priceless.

 
Non mais attends, t'as vu la gueule des arguments que tu sors aussi ? Entre les arguments d'autorité et le risible "ah mais * ça fait moins de bytes sur le réseau" faut quand même s'accrocher pour donner du crédit à ton avis sur ce coup là hein

ok, lol, donc un expert en développement web. C'est bien connu que ça rend expert en sql d'office.
Un trou du cul qui code en python a forcément raison, donc puisqu'il dit que c'est mieux, c'est mieux. Bravo masklinn, c'est ton meilleur argument de la semaine (mais on est que lundi hein, j'ai confiance en ta capacité de trouver un deuxième argument avant dimanche)

le risible "ah mais * ça fait moins de bytes sur le réseau"

ok, lol, donc un expert en développement web. C'est bien connu que ça rend expert en sql d'office.
Un trou du cul qui code en python a forcément raison, donc puisqu'il dit que c'est mieux, c'est mieux.

 
Non mais attends, t'as vu la gueule des arguments que tu sors aussi ? Entre les arguments d'autorité et le risible "ah mais * ça fait moins de bytes sur le réseau" faut quand même s'accrocher pour donner du crédit à ton avis sur ce coup là hein

 
sale con mon chien s est etouffé en bouffant des croquettes en forme d etoile

Et ton avis fait foi ?
 
Attends je tente un autre approche : Je viens de te dire que je partageais pas ton opinion.
 
C'est toi la failure pour le coup

Merci pour cette affirmation sans aucune justification qui fait vachement avancer le débat.

ben c'est du masklinn , quoi

 
Non mais attends, t'as vu la gueule des arguments que tu sors aussi ? Entre les arguments d'autorité et le risible "ah mais * ça fait moins de bytes sur le réseau" faut quand même s'accrocher pour donner du crédit à ton avis sur ce coup là hein

 
ok, lol, donc un expert en développement web. C'est bien connu que ça rend expert en sql d'office.
Un trou du cul qui code en python a forcément raison, donc puisqu'il dit que c'est mieux, c'est mieux. Bravo masklinn, c'est ton meilleur argument de la semaine (mais on est que lundi hein, j'ai confiance en ta capacité de trouver un deuxième argument avant dimanche)
 
se faire traiter d'attardé par un type qui dit que l'étoile c'est mieux qu'une liste de champs parce que ça coute moins cher en trafic réseau c'est quand même priceless.

C'est par ce que j'ai fait un petit peu d'assembleur que j'ai vraiment compris l'intérêt de langages comme le C.
C'est par ce que j'ai fait du C que j'ai compris l'intérêt de langages qui ne basent pas tout sur des pointeurs.
C'est par ce que j'ai utilisé pas mal de programmes orienté fonctions que j'ai vraiment compris l'intérêt des langages objets.
C'est par ce que j'ai utilisé du java que j'ai compris l'intérêt des langages libertaires et à l'inverse c'est par ce que j'ai fait beaucoup de php que je comprend l'intérêt des langages qui resserrent les boulons.
 
Bizarrement, t'as sortie cette réponse pour te foutre de la gueule de jubijub, mais dans le fond sa réponse est totalement vrai : il faut avoir utilisé plusieurs outils pour réaliser quels sont leurs avantages et inconvénients de chacun. Après c'est sur qu'on peut se passer de ce genre de connaissance, mais ça ne permet pas d'apprécier les langages à leur juste valeur.

T'as raison, pas plus rapide à envoyer sur le réseau, parser et exécuter d'avoir
(...)

T'as raison, pas plus rapide à envoyer sur le réseau, parser et exécuter d'avoir

SELECT * FROM `app_userprofile` WHERE `user_id` = 1

plutôt que

SELECT `app_userprofile`.`user_id`,`app_userprofile`.`account_status`,`app_userprofile`.`account_status_reason`,`app_userprofile`.`account_delete_type`,`app_userprofile`.`syndication_key`,`app_userprofile`.`blurb`,`app_userprofile`.`location`,`app_userprofile`.`country`,`app_userprofile`.`postal_code`,`app_userprofile`.`gender`,`app_userprofile`.`theme`,`app_userprofile`.`tiny_photo`,`app_userprofile`.`small_photo`,`app_userprofile`.`smedium_photo`,`app_userprofile`.`medium_photo`,`app_userprofile`.`large_photo`,`app_userprofile`.`orig_photo`,`app_userprofile`.`bday_month`,`app_userprofile`.`bday_day`,`app_userprofile`.`bday_year`,`app_userprofile`.`is_pro`,`app_userprofile`.`privacy_settings_id`,`app_userprofile`.`email_settings_id`,`app_userprofile`.`preference_settings_id`,`app_userprofile`.`ad_counter`,`app_userprofile`.`num_friends`,`app_userprofile`.`num_fans`,`app_userprofile`.`num_feeds`,`app_userprofile`.`num_blocked_fans`,`app_userprofile`.`num_friend_requests`,`app_userprofile`.`default_set_id`,`app_userprofile`.`invite_id`,`app_userprofile`.`invite_round`,`app_userprofile`.`avail_invites`,`app_userprofile`.`original_email` FROM `app_userprofile` WHERE (`app_userprofile`.`user_id` = 1)

et en plus c'est pas du tout plus simple à visualiser et débugger

Je prétends pas le contraire, sauf que la quantité de données que tu te prends dans la réponse elle varie ostensiblement à la hausse avec un select *

c'est que django devrait pas générer un paté avec tous les champs (qui plus est précédés du nom de la table, ce qui effectivement est complètement crétin dans un cas aussi simple) quand ça revient EXACTEMENT à faire un *.

Je vois pas trop en quoi, sauf dans le cas où t'as un blob, puisqu'on parlait de la sélection de la grande majorité (ou totalité) des champs

Et c'est tout aussi applicable (puisque fondamentalement il arrive strictement la même chose hein) dans le cas de SQL généré à la mano, d'autant plus dans la mesure où l'humain peut se rendre compte qu'il n'y a que 2-3 champs pas sélectionné et qu'au final il y gagnerait à tout sélectionner avec un select *, alors que l'ORM peut pas le déterminer

Quand vous aurez fini d'enculer les mouches pendant des pages ...

Dans le cas présent, je pense quand même que c'est à chacun de savoir s'il faut utiliser l'étoile ou pas

Sais tu combien de personnes meurent à causes des infections propagées par les mouches ? L'enculage de mouches sauve des vies !

Maintenant que tu le dis, je comprends que Masklinn soit très favorable à l'utilisation de l'étoile

Dans le cas présent, je pense quand même que c'est à chacun de savoir s'il faut utiliser l'étoile ou pas
 
Si tu fais une requête dans laquelle tu as besoin de la majorité des champs (voire tous), et que les champs dont tu n'as pas besoin sont "négligeables", autant utiliser l'étoile.
 
Maintenant si sur une table de 30 champs, on a besoin de n'en remonter que 2... autant les nommer.
 
Concernant ce que j'ai lu sur le fait qu'on ne sait pas comment aura évolué la table dans 2 ans, pour moi ça ne change pas grand chose...
 
Si tu rajoutes un champ, dans la majorité des cas il va falloir intervenir sur les requêtes pour le rajouter à la liste.
 
Donc reste à voir si on préfère passer sur X requêtes "*" dans lesquelles pour une raison qui doit être rare, on ait besoin de ne PAS sélectionner un champ ajouté, ou si on préfère passer sur Y requêtes "nommées" pour ajouter le nom du nouveau champ...

Si tu rajoutes un champ, dans la majorité des cas il va falloir intervenir sur les requêtes pour le rajouter à la liste.

Non, souvent une modification dans une table est liée à une nouvelle fonctionnalité...et donc pas de raison de toucher à ce qui existe.

Pas compris

Il dit que si tu changes la structure de tes tables, tu vas probablement reprendre toutes tes requêtes qui utilisent cette table de toute manière.
Je lui réponds que non, puisque dans le contexte (une modif qui rajoute des colonnes) ce sera probablement une nouvelle fonctionnalité, donc tes anciennes requêtes sur la table modifiée n'ont pas de raison de ne plus être valables.

Oui, mais tu vas surement en modifier certaine, sinon ton champs il sert a rien

il sert peut-être à une nouvelle fonctionnalité que tu développes quelque part, qui ne touche aucunement l'existant.