Reprise du message précédent :

Vieille vilole, fortifiée par vauban, longue histoire depuis les gallo romains, je passe dans le coin, clairement,  j'fais un tour la bas

tout le centre est fortifié et classé monument historique, la citadelle est à l'UNESCO, y'a 16 forts dans le système de défense, je sais pas combien d'églises, un opéra dans un style un peu taré (le même mec qui a fait les saline royales d'Arc et Senans).

Ok. Donc la fille était amatrice de belles pierres?

C'est pas faux.

Ou plutôt: tuez-les.

Et c'est quoi exactement leurs arguments, pour se passer de ces fonctionnalités essentielles ?

Même à lolmacon ils ont tout viré ...

@kadreg > Tu as bien raison, la peinture au plomb pose davantage de soucis mais les tuyauteries contaminent quand même pas mal ...

Edit > @nraynaud > Tu m'as fait envie d'aller visiter Besançon, faudrai que j'y aille ...

La perf.

 
Fuck that ? Why not fuck nraynaud instead. On the couch.

Bon, comme prévu. J'étais sûr que ce serait ça. Mauvais DBA --> changer DBA.
Le mec, il a trop la flemme d'optimiser les requêtes. Si la perf est si importante qu'il faille retirer toutes les contraintes d'intégrité, alors ce n'est pas une base de données qu'il vous faut, mais du NoSQL (car c'est comme ça que vous l'utilisez au fond). Dans ce cas, les DBA n'ont plus lieu d'être. Ensuite, vous faites toutes les jointures à la mano, ça veut dire que vos multiples requêtes doivent être soigneusement réfléchies pour éviter de ramener des tonnes de données inutiles. Au final, vous êtes obligés de faire le même boulot, en nettement plus dégueu, que la base elle-même.

edit: putain - google me dit qu'il me faut ruby1.8-dev; jsuis en 1.9 sur cette machine - et je suppose qu'un apt-get install rubygems1.9.1 m'a installé ruby1.9-dev… et meme en étant sur que -dev est installé, le gem plante toujours … me faut vraiment 1.8  ?

Alors je me corrige. On a pas de clés primaires mais on a des unique index sur une colonne ID
Pour le reste, c'est bien joli mais ici c'est la vraie vie, la pilule rouge, l'ENTREPRISE.

pas du tout elle était en route entre la Hollande et Cannes, et Besac était sur la route pour un pit stop.

mais du coup toute la perfs à l'insert est déjà bouffé par l'index.

Dire que NoSQL implique "pas de DBA", c'est se foutre un doigt dans l'oeil jusqu'au genou. Y a toujours besoin du gars qui va gérer la base, surtout si elle est distribuée et/ou que tu gères des milliards de lignes. C'est un métier un peu différent mais qui reste de la gestion de base de données.
http://omniti.com/seeds/why-nosql-does-not-mean-nodba

Surtout avec des technos moins robustes

Tain mais rubygem, c'est au moins aussi bien que les 2973 autres systemes de package sous nulix, en fait …
 

 
Parfait jsuis à Antibes  

Ba vala. Tu perds le côté ACID des RDBMS en passant sur du NoSQL, donc vaut mieux avoir des mecs compétents pour gérer le bordel. Au passage, Evernote a d'ailleurs fait le choix de rester sur du RDBMS pour le côté transactionnel.

 
Elle va pas s'arrêter si près du but. Puis maintenant qu'elle a connu nraynaud, tu vas paraître fade

Possible, je sais pas.

http://voxel.dl.sourceforge.net/pr [...] ssifier.py

 
Et qu'est-ce qui est supposé être drôle ?

mais les clés primaire c'est quand même la base du truc non ? Et surtout c'est quoi l'intérêt supposé de ne pas en avoir ?

 
Tu peux te mettre à faire du non-relationnel mais avec tous les inconvénients d'une base relationnelle, y compris devoir supporter des DBAs stupides.

Le fait que leur générateur de code soit pas capable d'émettre  " isDirty= condition (OR condtion)* ".

La plupart des entreprises farcissent leurs bases de contraintes relationnelles.
Juste par curiosité, quel usage vous faites de votre BD qui vous a décidé de supprimer les relations au niveau de la base ?

J'admets que j'ai pris un raccourci un peu rapide. Ton lien illustre très bien mon idée la-dessus.
La complexité supplémentaire du code signifie que les risques de bugs d'intégrité sont accrus:

Certaines bases NoSQL rajoutent une couche de SQL pour émuler les fonctionnalités des RDBMS.

Portage d'un existant PHP dev il y a environ 7 ans, je vous laisse imaginer la tête du code

$result = mysql_exec("SELECT * FROM cogip.users WHERE login = '" . $HTTP_POST_VARS["login"] . "'" );

 
S'il n'y avait que ça.
J'ai l'impression de revenir à l'époque où je débutais en PHP et que je foutais tout dans un même fichier. Sauf que je ne faisais pas de copier/coller de plusieurs dizaines de lignes pour modifier la condition d'un if et la valeur d'une requête

SEO Ipsum directory pagerank sculpting article spinning sem rush sem 302 404 authority copyscape 404 yahoo masking bot htaccess strategy link pushing link conversion copyscape fake pagerank eccomerce link farm doorway page alt attribute heading funnel http meta refresh redirect crawl frames domain 200 senuke filter adwords cookie eccomerce, traffic keywords 302 ip address validation title tag. Content network xrumer noscript stuffing spam google link farm map spam canonical open site explorer doorway page browser proxy rank masking, link pushing fiverr hidden links bing bot domain feed volume. Strategy feed eccomerce longtail adsense senuke open site explorer volume hijacking proxy social networking proxy 302 article spinning analytics redirect keyword stuffing rank spinnerChief blog comments fiverr linkscape content network copyright open site explorer on page whois scrape marketing scrape, volume sem rush 200 cookie link pushing 301 senuke. Link building slurp cloaking redirect keyword conversion, blog fake pagerank majestic pagerank sculpting brand 302 adwords domain bing bot adsense on page open site explorer on page redirect funnel pagerank funnel robot canonicalization phish meta refresh title tag. hijacking authority google bot bing page meta tag gzip spinnerChief sitewide links robot anchor text robot density bing bot keyword stuffing link pushing hidden links adwords spoof anchor text clickjack longtail scrapebox alt attribute, phishing masking senuke link blogroll link pushing alt attribute xenu on page slurp browser user agent ip delivery volume optimization whois 302 strategy cookie stuffing url spam strategy spam optimization spamdexing phish masking link pushing title tag noscript stuffing sitemap spoof http pagerank link pushing 302 domain link farm spamdexing. Bing speed directories sitewide links link farm user agent serps whois page rank browser 301 link schemes ip delivery, black hat spamming spoof xrumer longtail ip delivery phishing doorway page javascript google hijacking bing bot url frames spider strategy external link. Fake pagerank spamdexing gzip conversion validation malicious code 301 canonicalization spammy, off page robot redirect link building serps crawl. Keywords, off page copyscape conversion links slurp internal link analytics iframes sitemap, copyright hacker.

Alors apparemment les colonnes "identity" sur sybase sont implicitement des primary key ou un truc dans le genre, et c'est ça qui est utilisé. Plus l'index unique dessus donc. Le pourquoi j'en sais fichtre rien.

Usage classique, c'est une base qui sert à un frontal web, est alimentée par des référentiels, des markets data, des résultats de moteur de calculs. Tout ça fait une "belle" volumétrie et quant au pourquoi, je sais toujours pas.

Ils codent les relations en dur coté des clients de la base, il n'y a plus besoin de clefs primaires si ce n'est pour garantir l'unicité des lignes (ce qui me parait le strict minimum). L'intérêt, j'imagine, c'est qu'on peut, si on veut, migrer facilement les tables sur plusieurs bases et lancer les requêtes en parallèle, les jointures étant réalisées à la mano. Mais cela implique qu'il n'y ait pas des relations many-to-many entre plusieurs tables énormes, sinon les clients risquent de récupérer bcp trop d'information ou de multiplier les requêtes et les perfs s'écroulent.
L'autre gros problème dans une architecture de ce genre, c'est qu'il faut maintenir l'intégrité des relations entre tables à la mano au niveau des insert et des deletes, c'est infernal à gérer si le RDBMS ne gère pas les two-phase commits. En fait, ça n'est viable que s'il y a très peu de tables, qui sont requêtées 95% du temps, sinon c'est même pas vraiment ACID. 'fin bon, c'est problèmes, c'est pas nouveau, c'est pour les résoudre que les base de données relationnelles ont été inventées.

Pour ça que la solution de retirer les contraintes relationnelles, c'est vraiment pour moi la solution ultime, quand vraiment tout le reste a été essayé et est démontré insuffisant, y compris l'ajout de multiples niveaux de cache et la suppression de la couche ORM, qui est encore un moindre mal.

y'a pas une histoire d'age de la bdd ? genre oracle jusqu'a V5  y'avais pas de clés
chez nous c'est comme ça  

En fait, c'est drôle la série Un Gars, Une Fille.  
 
Vous connaissez ?  
 
Ca raconte la vie de couple de Chouchou et Loulou (c'est pas leurs vrais prénoms, hein). On s'y retrouve tous un petit peu en fait.

Le truc sur M6 là. Ouais j'adore je regarde tous les jours avec ma moitié. Mes préférés c'est les deux petits vieux qui s'engueulent tout le temps lol

dites, je viens de découvir "marc et sophie", Vous connaissez ?  
 
Ca raconte la vie de couple. On s'y retrouve tous un petit peu en fait.

Moi je préfère "vivement lundi".
 
Ca raconte la vie au bureau. On s'y retrouve tous un petit peu en fait.

je connais pas

http://fr.wikipedia.org/wiki/Vivement_lundi_!

dites, je viens de découvir "faites rentrer l'accusé", Vous connaissez ?  
 
Ca raconte la vie de psychopathes, Dion s'y retrouve un petit peu en fait.

Dites, je viens de découvrir "Romulus et Rémus". Bon c'est gravé sur des tablettes de cire à la con et c'est en latin, mais on s'y retrouve tous un petit peu en fait.