Reprise du message précédent :

 
tu assumes enfin ta relation avec moinsmoins ?

-- a une pedo stache ?

 
Je suis embauché en tant que dev PHP, pour toucher un peu à tout : sf2, magento, drupal, wordpress, etc. mais aussi du front sur des projets utilisant bien html5 et js qui ont l'air plutôt cool. J'en serai plus en septembre

Du coup vous gérez comment la montée en compétences des équipes tech ?

La majorité (lire: totalité - 1) n'a pas de problème avec poser (ou répondre à) des questions, ou avec les critiques, ou avec de l'échange de connaissances, .... Donc c'est pas un problème.

Il y a juste collègueG qui est... fatigant. Il est pas mauvais, il est même souvent bon ('fin quoi que, avec ce coup ci j'ai du mal quand même) mais c'est un connard agressif (et je m'y connais en connards), genre Dion mais IRL et sérieux. Ou Gatsu il y a quelques années dans le topic web. Ou moi mais plus agressif et encore plus suffisant.

 
fake

c'est moi ? \o/

Oui j'ai aussi été choqué, on me l'aurait dit je l'aurais pas cru.

Bien essayé, mais trop haut niveau technique et trop bas niveau de connarditude.

Sur ce domaine la si machine est finaliste toi tu es meme pas selectionne en equipe nationale

En gros c'est la copie mais il doit pas avoir l'air sympa qu'ont les gros

Chais pas si c'est que mon air naturellement jovial, je suis jamais allé assez loin pour me faire insulter de face par un collègue excédé, lui si

D'autant plus que le gros jovial c'est pas un avantage terrible en belgique, ils ont une sérieuse production locale donc ils ont des résistances.

Fig 1: le mec qui avait pas prévu de faire son coming-out cette semaine.

Il a peut etre pas le niveau technique pour les secher

Au moment ou tu t'appretes a passer la douane americaine c'est normal
-- > je sais pas pourquoi ca tombe sur toi

http://www.staggeringbeauty.com/

Also, c'est bientôt l'heure de prendre la porte à droite.

Gaffe, ça fait grossir

Les mecs aggressifs  

Dernz

Nop  

Preums

Les dessins sont super sympa

Bon, sinon, petite question base de données avant que je sois obligé de faire un test moi-même.
Harko, si t'es dans les parages...

J'ai des données de mesure auxquelles je ne vais accéder qu'en lecture, qui se présentent sous forme de tableaux de ~1500 doubles (via Hibernate). Pour l'instant, on les stocke individuellement. Je ne suis pas persuadé que ce soit optimal niveau perfs et stockage, sachant que 250ko de données sous forme texte se traduisent par 1Mo supplémentaire sous PostgreSQL (si on inclut les index). En fonction des configs, on atteint quelques dizaines de Go d'acquisition/jour dans le schéma actuel. Question: vaut-il mieux les stocker sous forme d'une longue string ? (je pense qu'on va quand même éviter les BLOB, par convénience).
Un calcul simple donne:
string: 1500 x 18-20 octets = 27000-30000 octets/ligne + un index (entier sur 8 octets ?)
doubles: 1500 x 8 octets + 1500 index = 24 000 octets

Dans le premier car, le retrait est probablement plus rapide mais il faut ensuite faire les conversions texte--> double, probablement négligeables/extraction.

1. C'est pas un peu un risque de premature optimization?
2. C'est quoi le reste du schéma, chaque array de ~1500 doubles est attaché a un record dans une table spécifique ou bien ils sont "free-standing"?
3. http://www.postgresql.org/docs/9.2/static/arrays.html

Et, heuu, la longue string pour stocker 2.5879846537, au lieu de prendre 64b t'en prends 96

1. non, sur un schéma de base, c'est pas prématuré, dans la mesure où une fois en prod, c'est fini, on ne peut plus optimiser ensuite (ou difficilement), surtout sur des volumes de données aussi importants et dans un environnement temps réel,
Par contre, c'est p-ê foireux, comme optim, cf mon edit
2. En gros, de mémoire une donnée comprend 9 arrays de 1500 doubles qui sont rattachés à un record de paramètres d'acquisition
3. oui j'ai vu, mais je ne sais pas si Hibernate gère ça, c'est spécifique Pgsql, il me semble. Et le seul intérêt des arrays, de ce que j'en retiens, est de pouvoir faire des accès sur les données individuellement dans les requêtes. A priori, nous n'aurons pas ce besoin-là.

La doc de Postgres est un peu légère, je trouve, elle ne permet pas de répondre à ces questions-la.

http://www.01net.com/editorial/571 [...] -quun-pas/
 

On peut aussi s'attendre assez logiquement à un format de stockage efficace (genre qu'un array de n doubles prenne 64*n bits + un poil d'overhead)

UserType

J'ai du mal à voir les questions en question, là, en dehors de "est-ce que j'utilise ma db comme une db ou comme une blobstore" à la limite, mais ça c'est assez spécifique à une application, je vois pas comment la doc de la db pourrait y répondre.

Et accessoirement, pourquoi "éviter les blobs"? il n'est pas plus difficile d'interagir avec un bytea qu'avec une chaîne si tu extrais tout d'un coup dans tous les cas, et ça peut permettre des tricks genre packer l'array et le compresser (avec un truc rapide) avant de l'écrire (même si je doute que la compression soit terrible) => 12000 octets par ligne (avec zlib ça descend à ~11500 mais bon ça casse pas 3 pattes à un canard comme gain) + index. Parce-que à ma connaissance dans un char tu peux pas mettre de NUL.

Possible

Ben par exemple, combien prend un index en base, ou des infos permettant une estimation de la taille de la base ou de son accroissement. Sachant que j'ai 1Mo environ par donnée, il semblerait que près des 3/4 de l'espace sont occupés par les index ou alors j'oublie qq chose.

Sinon, le genre d'info issu d'expérience (mais vachement datée, depuis, le vacuum a bien changé, un vacuum full est moins souvent nécessaire):
Sur une base de 5876 Mo,
vacuumdb/reindexdb:           190min - 1990MB
reindexdb/vacuumdb/reindexdb: 105min - 1990MB
dump/dropdb/createdb/restore:  20min - 1685MB

http://www.linuxinsight.com/optimi [...] _size.html

Ca va dans le sens des index qui prennent une majorité d'espace dans les proportions que j'ai estimées.
Et qq chose à laquelle je n'avais pas pensé, le table partitioning (ça c'est documenté): http://dba.stackexchange.com/quest [...] nsor-array

Parce qu'on ne peut pas voir les données directement en base avec un outil SQL standard. On ne peut pas faire un copier-coller dans une feuille Excel et faire un plot rapidement, il faut faire uneextraction de la ligne puis une conversion, bref, c'est pas super pratique pour débugger. Mais bon, c'est pas non plus la fin du monde donc je n'exclus pas totalement cette solution.

Le chapitre 55 de la doc te donne pas des infos là dessus?

T'as l'option d'un tablespace dédié qui stocke son bordel dans un filesystem compressé aussi.

edit: et le partitioning, je sais pas si ça va massivement réduire la taille de la db.

ah oui tiens je l'avais pas vu
Je vais y jeter un oeil.

en fait, c'est en cherchant des infos sur la création des tablespaces que je suis tombé sur le partitionnement de tables. Ca ne réduit pas la taille de la base, mais c'est censé aider dans la purge, comme l'explique le gars de stackexchange, et il est probable que le client veuille régulièrement purger les données les plus anciennes (genre tous les x mois), ce qui risque de représenter des To de données et donc de mettre la base à genoux pendant des heures ou des jours si on ne fait pas attention.

Ça oui, mais t'avais pas causé de ça, donc j'étais parti du principe que les données étaient pas supprimées

C'est quoi l'intérêt de les foutre dans une BD ?

Bon je casse un peu la discussion sur la DB pour discuter des ampoules à économie d'énergie.
J'ai 2 ampoules Philips qui ont claqué ces dernières semaines après moins d'un an d'utilisation  
Des conseils sur les marques d'ampoules qui vont bien ?
Parce qu'à 11€ l'ampoule ça fait un peu chier qd même.

C'est l'intérêt d'une BD: pouvoir requêter facilement et rapidement  sur divers critères.

Philips ?

 
 
Ben non, justement, t'as du prendre une bas de gamme voir de la contrebande.

Elles ne sont pas garanties plus d'un an, les Philips ?
Vu l'arnaque que c'est, la loi devrait se pencher dessus et obliger les fabriquants d'ampoules à fournir 2 ans de garantie. Au niveau européen si possible.

Sur l'emballage y a marqué 12000 heures => 12 ans d'utilisation

http://www.cringely.com/2012/08/14 [...] shion-way/
y'en a qui se font même pas chier avec des bots ...

Ca fait des journées de 3h. Si tu garantis une durée, c'est forcément 24/24. Mais en fait, il faut aussi garantir un nombre d'allumages, parce que je soupçonne que c'est là que le bât blesse. Tes ampoules on claqué à moins de 400 allumages.