Je comprend que vous ayez cette vision des choses.

Je fait parti d'une boite où nous nous permettons de conseiller très fortement le client.
Je travaille sur le plus gros diffuseur de pub français et je peut te dire que quand on conseille au client ne nous donner plus de temps pour ne pas rendre bancal la diffusion, il nous écoute.

Toute la journée, je travaille sur comment modifier le schéma de base de données sans mettre la diffusion HS pendant 4h ... et on se démerde pas mal ...

Je me tiens toujours au maximum à la vision théorique des choses, ce qui, jusqu'a maintenant, correspond à la vision des choses de mon boss et nous permet de ne jamais se diriger droit dans un mur.

Effectivement, j'utilise aussi certains passe-droit pour ne pas avoir à passer 6h là où 10mn suffisent.
Toujours est-il que sur une base de données, je ne me le suis jamais permis, et je n'ai jamais démonté une base, même une base qui collecte plusieurs milliards de hits par jours

Je comprend que vous ayez cette vision des choses.

Je fait parti d'une boite où nous nous permettons de conseiller très fortement le client.
Je travaille sur le plus gros diffuseur de pub français et je peut te dire que quand on conseille au client ne nous donner plus de temps pour ne pas rendre bancal la diffusion, il nous écoute.

Toute la journée, je travaille sur comment modifier le schéma de base de données sans mettre la diffusion HS pendant 4h ... et on se démerde pas mal ...

Je me tiens toujours au maximum à la vision théorique des choses, ce qui, jusqu'a maintenant, correspond à la vision des choses de mon boss et nous permet de ne jamais se diriger droit dans un mur.

Effectivement, j'utilise aussi certains passe-droit pour ne pas avoir à passer 6h là où 10mn suffisent.
Toujours est-il que sur une base de données, je ne me le suis jamais permis, et je n'ai jamais démonté une base, même une base qui collecte plusieurs milliards de hits par jours

On n'est sûrement pas si différents . C'est juste une question de marge de manoeuvre.

D'un boulot à l'autre, les besoins ne sont pas les mêmes, la réflexion en amont et les interlocuteurs non plus, et ça peut tout changer. Là où je suis en ce moment j'aurai plutôt tendance à choisir l'architecture la plus élégante et la plus maintenable (priorité aux données). Dans ce job dont je parlais plus haut, il s'agissait vraiment d'aller vite et de produire du jetable. Il y a un monde entre les deux

Oui, sauf que dans mon cas, les clients sont des clients interne. Et les conseilles, c'est même pas la peine d'y penser (j'ai essayer une fois, je m'en remet doucement). Sauf si c'est un avis technique ou une impossibilité technique, le reste, il me diront que c'est pas mon domaine. Idem pour la BDD et idem pour la gestion des serveurs (physique ou apache). Moi, la seule chose sur laquelle je peux faire qq chose, c'est les sources. Je n'ai pas accès ni aux serveurs d'intégration, ni aux serveurs de prod. C'est très cloisonné et chaque service est jaloux de ses prérogatives. Y a même des moments ou on a l'impression de bosser dans des boites différentes. Enfin, ceci mis a part, ça reste très intéressant techniquement.

Beuh justement, c'était un débat intéressant et il méritait bien un sujet pour lui tout seul m'enfin bon, puisqu'on en est à pourrir celui-ci....

Quant à sérialiser un objet en base, j'en suis pas fan non plus. Tout dépend du contexte évidement, mais si jamais l'objet stocké évolu (que ce soit en milieu de projet ou 3 ans après parce qu'on a toujours de nouveaux besoins) ça devient une véritable galère à remettre à jour dans la base...

Là où je suis 100% d'accord, c'est que quand on te donne un cahier des charges et te disant +/- clairement "ferme ta bouche, c'est déjà décidé", tu peux en venir à faire des choses qui ne te plaisent pas mais sans pouvoir donner ton avis

@titerm : tout pareil...
@zeus : oui c'est bien ça. serialize() dans ce cas est un couteau suisse bien appréciable.
@Ryle : C'est un débat intéressant oui. Je pense qu'on pourrait l'élargir à "Peut-on produire autre chose que du quick and dirty avec serialize() ?"

Et pour ce qui est du contexte, c'est pouvoir de décision/conseil/réflexion pas loin de zéro, et horizon de développement : très court terme La question de l'évolutivité à 3 ans est nulle et non avenue dans ce cas. Mais en effet, ça condamne tout du coup, ce n'est pas un choix à faire à la légère.

Tout dépend du contexte évidement, mais si jamais l'objet stocké évolu (que ce soit en milieu de projet ou 3 ans après parce qu'on a toujours de nouveaux besoins) ça devient une véritable galère à remettre à jour dans la base...

@ryle: Dans mon cas, le fait que la donnée soit sérialise donne beaucoup de souplesse et évite d'avoir a faire des MAJ BDD. Mais je n'ai peut être pas éte assez précis dans ma façon de faire. Je n'exploite pas directement l'objet désérialise mais je passe par une méthode de l'objet qui reconstruit elle même l'objet. Je travail donc toujours avec la dernière version de l'objet même si j'ai des propriétés qui ne sont pas renseigné, ce sont les accesseur qui géreront le défaut.

class objLien {
	public $href;
	public $label;
	public $target;
	
	public function get() {return serialize($this);}
	public function set($v) {
		$tmp = @unserialize($v);
		$list = array_keys(get_object_vars($this));
		foreach($list as $attr) {
			$this->$attr = empty($tmp->$attr) ?  null : $tmp->$attr;		
		}
	}
	public function __set($attr, $value) {$this->$attr = $value;}
}


class objLien2 {
	public $href;
	public $label;
	public $target;
	public $accessKey;
	
	public function get() {return serialize($this);}
	public function set($v) {
		$tmp = @unserialize($v);
		$list = array_keys(get_object_vars($this));
		foreach($list as $attr) {
			$this->$attr = empty($tmp->$attr) ?  null : $tmp->$attr;
		}
	}
	public function __set($attr, $value) {$this->$attr = $value;}
}

$foo = new objLien();
$foo->href = 'http://www.google.com';
$foo->label = 'Google';
$foo->target = '__parent';

$r = $foo->get();

$foo2 = new objLien2();
$foo2->set($r);
var_dump($foo2);

Imagine que tu gères un objet lien (avec url, label, target, les events etc...). Tu stocks la version serialisé dans la base. ObjLien

Plus tard, tu veux ajouter la navigation clavier et donc ajouter l'attribut ACCESSKEY. Tu met a jours l'object (ObjLien2). A partir de maintenant, tu peux gérer cette propriété. Soit elle n'est pas renseigné dans les ancien objets auquel cas, c'est le webmaster qui devra la renseigner, soit elle l'est et tu peux la traiter.

Plus tard encore, tu passes au HTML strict. Donc l'attribut target devient interdit. Tu peux le supprimer de la classe ou simplement l'ignorer dans les méthodes de la class, dans le toHTML() par exemple, ne en faire plus le rendu.

C'est juste un exemple simplifié pour donner une idée.