Modérateur Delphi
Le guide du bon forumeur :
- Les règles du forum tu liras
- La FAQ et les tutoriels tu consulteras
- La fonction Recherche tu utiliseras
- Google tu vénèreras
__________
Rayek World : Youtube Facebook
Oui en COBOL, quand il y a des bases de données hiérarchiques donc, mais surtout pas en base de données relationnelles.
J'ai travaillé il y a pas longtemps (il y a moins d'un an) sur une base AS400 DB2/UDB et là il n'y avait pas photo, les requêtes avec jointures étaient plus rapides que ta solution pour peu qu'il y ait les bons index. En plus c'était pour des batchs.
Après il y a un moment où il faut quand même faire plusieurs étapes pour qu'il y ait plus de clarté dans le code et moins de volume, on est d'accord.
En tout cas il faut s'adapter au SGBD sous jacent, et utiliser du SQL hiérarchique, quand la base est faite pour cela, comme dans ton cas, ou du SQL relationnel quand la base est faite pour cela
ha ha le naze. Qu'on le remplace par quelque chose d'autre, pourquoi pas, bien que je trouve que c'est bien d'avoir un langage ensembliste et un moteur dédié base de données qui va avec, mais vouloir l'enlever en laissant du code en curseurs pour un moteur de base de données qui n'est pas fait pour cela, c'est absurde tant qu'il n'y a pas d'alternatives ou de nouveautés à ce sujet. C'est tellement mort que ça survit depuis bien plus longtemps que d'autres langages.
En fait c'est son argumentation qui est naze plutôt que le choix en lui-même s'il ne connait pas le SQL ce qui serait plus compréhensible.
Hummm pas vraiment d'accord avec ça moi.
Dans la plupart des sites web il y a souvent un seul SGDB, quand les frontaux sont souvent plus nombreux et sans état.
Comment peux-tu dire que confier plus de boulot au single point of failure de ton application est bon pour la scalabilité? Pour moi c'est tout l'inverse...
Si déléguer un peu de boulot sur les frontaux qui scalent mieux peut permettre a ta base ne baisser en charge je ne vois vraiment pas le problème et ça t'éloigne du point de rupture des perfs de ta base. Bien sur il ne faut pas que les frontaux fassent pour autant plus de requêtes sinon c'est l'effet inverse et les temps de réponse deviennent pourris...
Enfin bref moi ca me viendrait jamais à l'idée de demander a mon SGBD de formatter une date en string selon un format donné et un timezone donné juste pour dire que je vais pas le faire dans mon code Java...
Hahaha laisse moi rire
Tu as découvert Java dans les années 2000 à l'époque ou c'était le cas je présume?
Ca a un peu changé depuis quand même...
Dans les applications de trading haute fréquence on utilise plus que du C++, il y a aussi des datagrids implémentés en Java qui ont d'excellentes performances pour peu que la JVM soit tunnée correctement. Regarde un peu du coté de VMWare GemFire ou Oracle Coherence.
Les moteurs de recherche fulltext basés sur Lucene comme Solr ou ElasticSearch sont aussi implémentés en Java
Il y a plein de projets qui sont réputés pour traiter un grand nombre de données, et pas forcement que pour du web, je pense a Hadoop par exemple.
Sur Wikipedia:
However, high performance computing applications written in Java have recently won benchmark competitions. In 2008[70] and 2009,[71][72] an Apache Hadoop (an open-source high performance computing project written in Java) based cluster was able to sort a terabyte and petabyte of integers the fastest. The hardware setup of the competing systems was not fixed, however.[73][74]
Je suis tout à fait d'accord, comme tu veux l'utilise ça n'a pas d'interet. Mais ce genre de bases ne s'utilisent pas comme ça, pas sur un vrai projet industrialisé pour lequel la consistance à une importance en tout cas... c'est la catastrophe assurée et une base rapidement corrompue dont on peut difficilement rattraper les données...
Ce genre d'outil s'utilise pour dénormaliser des données consistantes ou y stocker des données deja dénormalisées (au même titre que des moteurs de recherche comme ElasticSearch ou Solr d'ailleurs qui sont pas si éloignés de MongoDB que ça).
Ils peuvent venir en complement d'un SGBD normal pour le soulager en terme de charge (au même titre qu'on utilise des réplicats SQL au final) sur des vues ou l'eventual consistency est acceptable.
Et pour ceux qui ont besoin de faire 15 jointures pour sortir des vues très fréquentées je leur dis qu'ils feraient mieux de dénormaliser dans une base NoSQL comme MongoDB, voir une autre table SQL.
Sinon le SGDB n'est pas indispensable avec ces bases dénormalisées pour garantir la consistance, il existe des alternatives comme l'Event Sourcing ou le Command Sourcing.
Pour moi, faire plus de 3 jointures pour une ihm sur un site web a forte charge, c'est qu'il y a un problème derrière au niveau du stockage des données...
React-Hebdo - Newsletter pour se tenir à jour sur l'écosystème React
Salut Marco46 j'ai tout lu avec grand intérêt ; tout ça est très déplorable et inquiétant en même temps
"The hardware setup of the competing systems was not fixed, however"
Rien à ajouter.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager