> Bonjour,
>
Bonjour,
> je vais degonfler les chevilles de ce site mais la majorite sinon la
> totalite des "crack" ici n'utilise que des jouets comme SGBD car leur SGBD
> n'est pas Multivalué
Ah ?
> le fosse qu'il y a entre un SGBD relationnnelle et une SGBD Multivalue est
> equivalent a celui qu'il y a entre un Dbase (SGBD transactionnel) et MySQL
> (SGBD relationnel)
lol
>
> un SGBD Multivalue peux sur un simple Pc sous Linux ou Windaube gerer une
> base de 30000000 de fiches avec 500 utilisateurs et un temp de reponse
> normal
Huh ? PostgreSQL aussi
> un SGBD multivalue vaut 100 euro TTC par utilisateur combien vaut
> MS.ACCESS ?
0,00 pour PostgreSQL, Firebird, Derby ...etc
> un SGBD multivalue s'installe en 5mn
rpm -ivh ... 30 secondes
> les SGBD multivalue ont 40ans d'experiences
Hum, le basic est tres vieux aussi, on laisse tous tomber c/c++, java, C#,
ca pue, c'est trop jeune :)
> les SGBD multivalue tourne sur toute les plateforme hard du pc8086 ą
> l'IBM43 les SGBD multivalue sont sous tout les OS (linux, unix, windaube,
> dos,......)
Ah, donc sur un 8086 tu fais tourner "une base avec 30000000 de fiches avec
500 utilisateurs", interessant :)
> les SGBD multivalue sont compatible aux niveaux executable entre eux (pas
> besoin des sources pour changer de plateforme)
> les SGBD multivalue sont les plus répandus et les moins connus car ils ne
> se presentent pas aux utilisateurs grace ą des 'sortes de panneaux
> publicitaire bleu style : "Windaube est planté" '
PostgreSQL ne m'a jamais fais de panneau bleu...
Ah, merde, je crois que je viens de marcher dedans ...
On Fri, 24 Jun 2005 17:35:06 +0200, helios <helios....@free.fr> wrote:
> "LISTE DES CLIENTS AVEC UNE FACTURE NON PAYER > 100 EURO NOM PRENOM
> ADRESSE MONTANT DATE "
Ben c'est merveilleux, il comprend même les fautes d'orthographe ton truc!
Et puis c'est pas ambigu comme requête, c'est clair.
> CETTE REQUETTE ET CE RESULTAT EST IMPOSSIBLE AVEC UN SGBD RELATIONNELLE
select nom,prenom,adresse,montant,date from clients c,facture f where
f.client=c.id and not f.payee and f.montant>100;
Ah oui, s'il y a plusieurs factures non payées qui dépassent 100 euros il
te les donnera toutes, mais c'est une subtilité qui a du échapper à ton
truc génial.
Jacques.
Je dois etre con, mais c'est quoi une base de donnée multivaluée???
Etienne
Bon en gros, pour faire une analogie.
Un article est un fichier XML qui va contenir des données (et eventuellement
des sous données)
et puis le langage de requete qui va chercher dans les fichiers les couple
(attribut, valeur)
et retourner un ensemble de champ. c'est ca?
Est ce qu'on obtient pas la meme chose en placant un article par fichier XML
puis en utilisant swish-e pour indexer tout ca?
Etienne
> oui comme les boiteux et les unijambistes marchent, en Aout 2002 une grande
> entreprise francaise ayant un budjet informatique de 1Milliard d'euro a
> essayer de remplacer sa SGBD multivalue par PostgreSQL
On se demande pourquoi cette entreprise a voulu se débarrasser d'un
système aussi performant qu'un SGBD multivalue ...
Plus de compétence sur le marché ?
Trop cher à maintenir ?
Impossibilité de le faire évoluer ?
> justement resultat de
> l'experience tout les calculateur se sont ecroule sous la charge de travail
> necessaire par PostgreSQL pour gere la base qui tournait tres
> confortablement avec 5000 utilisateurs en periode de pointes (Aout est la
> periode ou les bases sont au repos meme au repos PostgreSQL ecroule le
> calculateur )>
Déjà on peut se poser des questions sur la compétence du DSI qui décide
de confier une telle base à PostgreSQL.
Ensuite on peut s'interroger sur les causes de l'échec de la migration.
Serait-ce parce que le modèle à l'origine était pas ou mal documenté ?
Peut être que dans un souci d'économie, il a été tenté de faire une
migration à moindre frais donc sans adapter le modèle (développé
originalement pour une base multivaluée) au modèle relationnel ?
Bref, l'outil n'est pas forcément en cause et une migration dans l'autre
sens (SGBD relationnel vers un SGBD multivalue) aurait probablement eu
les mêmes effets.
--
Bruno
http://errance.lirano.net (photographies)
Mais il est vrai que j'ai vu tourner des bases sous pick : c'était
relativement rapide. On a eu des performances inférieures en utilisant
des fichiers clipper à l'époque (ça date...). Mais les problèmes de
perfs ont été facilement résolus en remplaçant l'interrogation windev
par une interrogation avec une librairie écrite en C.
Si on veut parler des perfs : essaye de comparer une vieille application
clipper sous dos avec une appli sous windows xp... avantage au dos. Mais
y a eu des avancés windows sur d'autres points.
Quand à la sécurité des données, j'ai plus confiance en une base oracle
qu'en un vague truc sous pick ou mysql. Pour un site web de
consultation, je suis preneur (pq payer quand y a du gratuit qui marche
bien). Mais quand y a de la saisie d'info commerciale ou de production,
mon choix est vite fait.
C'est tellement bien votre ``truc'' que vous êtes obligés de spammer ici
pour espérer trouver des gog^H^H^Hclients ?
Merci d'arrêter donc vos spams ici, et aussi d'apprendre à répondre
correctement (cf vos quotes).
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
[snip]
> amplement suffissant et vaux 400euro ttc) les 500 utilisateur se connect en
> telnet par exemple via internet
En telnet ! Très intéressant pour la sécurité ça...
Ah, au fait. PostgreSQL possède une version native "windows"
depuis la version 8.0...
--
M.B
> Bonjour,
>
> je vais degonfler les chevilles de ce site mais la majorite sinon la
> totalite des "crack" ici n'utilise que des jouets comme SGBD car leur SGBD
> n'est pas Multivalué
>
Le helios a trop chauffé ;-)
> le fosse qu'il y a entre un SGBD relationnnelle et une SGBD Multivalue est
> equivalent a celui qu'il y a entre un Dbase (SGBD transactionnel) et MySQL
> (SGBD relationnel)
>
>
> un SGBD Multivalue peux sur un simple Pc sous Linux ou Windaube gerer une
> base de 30000000 de fiches avec 500 utilisateurs et un temp de reponse
> normal
>
> pour plus de detail sur les SGBD Multivalue : www.pick.com02.com
>
> un SGBD multivalue vaut 100 euro TTC par utilisateur combien vaut MS.ACCESS
> ?
> un SGBD multivalue s'installe en 5mn
> les SGBD multivalue ont 40ans d'experiences
> les SGBD multivalue tourne sur toute les plateforme hard du pc8086 à l'IBM43
> les SGBD multivalue sont sous tout les OS (linux, unix, windaube,
> dos,......)
> les SGBD multivalue sont compatible aux niveaux executable entre eux (pas
> besoin des sources pour changer de plateforme)
> les SGBD multivalue sont les plus répandus et les moins connus car ils ne se
> presentent pas aux utilisateurs grace à des 'sortes de panneaux publicitaire
> bleu style : "Windaube est planté" '
>
>
>
Je ne comprends pas pourquoi, vous êtes agressifs, il suffit de dire
ce qu'est un sgbd multivalue en donnant des liens (un peu plus parlant
que celui que vous donnez)
je mets quelques liens pour ceux qui comme moi essaie d'avoir
une meilleur idée de quoi on parle
http://kiosque.rainingdata.fr/article.php3?id_article=109
http://kiosque.rainingdata.fr/
http://www.maverick-dbms.org/
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
sql sera généralement plus lent : il faut analyser l'ordre sql (analyse
sémantique / syntaxique), interroger le dictionnaire de données et les
statistiques, définir le plan d'exécution (ou voir si il est en
cache)... Et après seulement, on fait le vrai travail.
avec un format dbase, le programmeur a fait tout le travail préliminaire
dans sa tête et il n'y a plus que l'interrogation de la base.
l'avantage de sql sur les fichiers à plat, c'est surtout la sécurité et
la souplesse. Par exemple, si la volumétrie change de manière radicale,
une simple mise à niveau des stats remet les pendules à l'heure alors
qu'il faut revoir les algos en dbase.
euh... dans les administrations, j'ai eu plein de contrats pour
remplacer des systèmes pick par des applications utilisant des fichiers
à plat (dbase sur serveur novell - à l'époque, les sgbd gratuites
n'existait pas encore - pour de petites volumétrie / faible nombre
d'utilisateur) ou oracle dans le cadre de grosse volumétrie (plus souple
à faire évoluer).
> Mr Parick Mevzek vu votre age (28a) que connaissait vous de l'informatique
> Reelle ?
> vous ne connaissait que ce que les universitaires vous ont montre rien
> d'autre , pour vous l'avion a reaction est mauvais car il n'a pas d'helice
> et Archimede etait un ane puisqu'il a utilise l'energie solaire plutot qu'un
> lance flamme pour brulle les voiles des ennemis (si le solaire etait bon il
> n'aurait pas besoin de subventions et les profs de physique nucleaire
> l'enseigneraient ......)
>
>
>
>
>
>
>
>
> la securite se gere au niveau du SGBD MV pas au au niveau du protocole de
> transmissions
Non, la sécurité se gère aux deux niveaux.
Avec du telnet via Internet, un bon sniffer devrait pouvoir mettre à mal
la "sécurité" sans trop de problèmes...
> on peut aussi faire de l'intranet ou meme de la ls
Et donc des coûts supplémentaires qui se rajoutent au coût de votre bouzin.
--
Bruno BAGUETTE - bou...@alussinan.org
> Mr Parick Mevzek vu votre age (28a) que connaissait vous de l'informatique
> Reelle ?
[---snip les conneries d'helios---]
Vous êtes à court d'arguments que pour tomber si bas dans les attaques
personnelles ?
Résumons :
- Vous débarquez sur un forum et vous gueulez "Bougez vous tas de cons
avec vos jouets minables, regardez mon truc qui est LA solution !"
(peut-être pas dit ainsi, mais pas loin).
- Votre site ne donne pas vraiment un sentiment pro : redirection ulimit
pointant sur un domaine acheté par une société offshore aux Comores,
avec un site au design merd^^^ discutable.
Bref, vous avez encore du boulot si vous voulez vous montrer plus
convaincant que ca...
> comment fait tu du multiposte en SQL sans telnet, ni ls, ni intranet ? quel
> technique securise utilises tu pour relie les terminaux ?
Noooon, ne me dites pas que vous n'avez jamais entendu parler de SSL ?
(pour ne citer que ca).
> comment fait tu du multiposte en SQL sans telnet, ni ls, ni intranet ? quel
> technique securise utilises tu pour relie les terminaux ?
Il est clair que le temps s'est arrêté il y a une trentaine d'année pour
toi.
Ne me dis pas que tu ne connais pas le concept du client/serveur qui est
d'ailleurs maintenant dépassé par le client web. Tu connais ?
Là, vous changez les données du problème.
Mais qu'à cela ne tienne, avec une petite recherche de rien du tout sur
Google, je suis tombé sur une page reprenant divers terminaux internet,
certains sont équipés d'un processeur Geode, et la majorité supportent SSL :
http://www.iapplianceweb.com/appTable/IAW_INTERNET_TERMINALS.htm
Si vous ne parlez pas de ce type de terminal, soyez un peu plus précis,
pour une fois...
Ah bon ? Et votre post n'est pas du spam peut-être ?
J'imagine que le helios de votre email (même pas la décence de signer
avec son nom...) n'a rien à voir avec le helios dans les pages
Freelances "partenaires"
de votre lien ?
Vous pensez vraiment que les gens sont aussi idiots que ca ?
> et devinez qui est un des plus gros utilisateur de SGBD MV au USA ?
On s'en fout, vous savez, de votre avis et de vos spams !
(et alternativement de votre étalage de pseudo-connaissances et de
pseudo-maitrise des bases de données)
> Mr Parick Mevzek vu votre age (28a) que connaissait vous de l'informatique
> Reelle ?
On se connait ? Je ne crois pas, et donc plutôt que de dire des
âneries à côté de la plaque (d'un autre côté vous continuez sur
votre lancée initiale), remballez votre ton
hautain et sûr de lui et repartez jouer avec votre solution miraculeuse
que vous conseillez à plein de sociétés qui économisent plein d'argent
grâce à vous.
Encore une fois je le répète: vos spams ne sont pas bienvenus ici !
Vous ne connaissez pas trop et pourtant vous vous permettez d'avoir un
avis sur tout ?
Vraiment, merci pour le fou rire, vous êtes à plier de rire !
Par contre, question récupérer des gog^H^H^Hclients ici, je crois que
c'est raté, donc merci d'aller voir ailleurs.
> en pick lorsque la volumetrie change on ne fait rien c'est prevue
Et la marmotte met le chocolat dans le papier, c'est connu....
Pick s'est visiblement très bien vendu à son époque. Maintenant, pour
une très large partie des références citées, il reste encore quelques
bases sous Pick car il ne reste plus grand monde qui maitrise ce système
et que sa disparition (généralement ardemment souhaité par la plupart
des personnes encore en place) implique un nouveau développement à
partir de zéro. Donc il dure ...
J'ai connu cette situation dans une grande entreprise. La comptabilité
est (ou était car cela a pu changé depuis ....) sous PICK. Le système
était maintenu par des personnes proche de la retraite. Personne n'était
en mesure de savoir ce que faisait précisément ce système ! Les
prestataires connaissant ce système sont rares et donc chers. Le système
était conservé parce qu'il n'y avait pas réellement le choix ...
Voilà pour la présence dans toutes les administrations... Si ça se
trouve, PICK y tourne sous GECOS avec des BULL... Mais ces mêmes
administrations font tourner tous leurs nouveaux projets avec une base
de données relationnel !
On se demande d'ailleurs pourquoi le modèle relationnel a s'imposer sur
le marché des bases de données alors qu'il est plus récent que les SGBD
Multivalue. Accuser l'Education Nationale d'avoir formaté les cerveaux
serait une explication franchement simplette.
Je peux donc comprendre votre rancoeur mais cela ne vous autorise pas à
ces attaques bassement personnel qui n'ont rien à faire sur ce forum
comme votre message initial qui s'apparente clairement à un SPAM.
Et donc vous spammez ce newsgroup. Pour la troisième fois: cessez !
> la visite de ces adresses y est tres instructif
Je suis heureux de faire travailler votre intelligence. Malheureusement,
vous ne semblez pas savoir l'employer à bon escient.
> quand avez vous travaille sur des vrais
> bases de donne en entreprise ?
Parce que vous croyez que j'ai envie de discuter avec vous ?
Outre le fond (vous spammez) sur la forme vous croyez déjà tout savoir
en étant tout fier de montrer que vous savez utiliser votre navigateur.
Tant mieux pour vous, mais apprenez que je n'ai rien à justifier devant
vous.
> besoin de spams pour y attirer des intervenant?
Contrairement à vous, je ne spamme pas les newsgroups.
Et je ne me rends pas ridicule en continuant de dire toujours la même
chose alors que tous les intervenants vous demandent d'arrêter, tant sur
le fond que sur la forme.
Allez-y continuez, le week-end n'est pas terminé....
Mon père n'est plus de ce monde, donc merci de le laisser en dehors de
votre délire hors proportions...
> et il faut trouver des
> clients et les activites de la societe ne rapporte rien ,
Vous avez eu accès au dernier bilan ?
> il y a un forum ou le seul intervenant est la societe
Cela vous pose un problème ? Vous êtes jaloux, vous ne savez pas monter
de serveur de news privé, je vous apprend si vous voulez, si ca peut
faire que vous arrêtez vos délires ici, ca serait parfait !
Le train de vos insultes roule sur les rails de mon indifférence.
Le concours des citations est lancé...
Et si vous ne savez pas encore qu'il ne faut pas croire tout ce qu'on lit
sur Internet, ca montre à quel point vous maîtrisez les outils que vous
utilisez... :-)
> comique le messieur a quoi sert un news prive ?
Revenez quand vous saurez. Ca nous fera des vacances d'ici là.
Sinon, ca va les chevilles, monsieur bac+8 qui maîtrise les SGBD ?
(mais pas de quoter correctement apparemment, on ne peut pas tout demander
j'imagine...)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépęches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Une discussion technique et objective avec des gens qui ne sont pas
bornés, peut-être.
Un spam d'un prestataire qui essaye de vendre sa solution, certainement
pas.
> contrairement au parasite qui essais de s'immisser entre ceux qui veule un
> nom de domaine et les registrars
Essayez de ne parler que de ce que vous connaissez (si cet ensemble n'est
pas vide), ca vous éviterait de vous ridiculiser davantage à chaque
phrase...
> celui qui n'a rien fait ne peux rien montrer erreur je reconnait mes
> ignorances contrairement a certain bourrez d'orgueil par leur minable
> bac+5 (j'ai bac +8) et les experience ridicule en sgbd (jamais
> reellement utilise)
Question orgueil, ca se pose là, effectivement....
> c'est pas du spams des interventions sans cesse sur un sujet que l'on
> ignore dans un forum sgbd ou on ne cesse de donnnez les adresse de
> parasite qui s'immisse entre les acheteur de nom de domaine et les
> registrar car quel est l'utilite de la societe cache dernieres les
> addresse que bvous cesser de donner a chaque message ?
Cf remarque précédente.
> qu'est ce que Dot and co vient faire dans les SGBD sinon du spams ?
Personne n'en parle, à part vous puisque cela semble être le maigre seul
argument que vous trouvez...
> le relationnelle a occuper une niche laisser vacante entre le dbase sur
> micro et le pick sur mini , PICK est maintenant sur micro donc exit le
> relationnel
C'est ce genre de propos qui discrédite tout votre discours.
Je ne connais pas les chiffres mais je suis convaincu que la part des
bases de données relationnelle est écrasante par rapport aux autres
types de base de données.
Il faut croire que PICK est resté beaucoup trop longtemps sur les gros
systèmes avant de s'ouvrir sur les autres systèmes. Généralement, cela
ne pardonne pas.
> par contre la majorite des grosse base sont sur PICK (nombre users taille
> fichier) tandis que effectivement le SQL est majoritaire sur les applis
> moins 10 users mais cela peut changer car PICK sait faire aussi cela
Y aurait-il des sources indépendantes confirmant ces propos ?
Car réduire le marché du modèle relationnel aux applications avec moins
de 10 utilisateurs est totalement caricatural.
Pour les plus grosses bases :
http://www.wintercorp.com/vldb/2003_TopTen_Survey/TopTenWinners.asp
Les moteurs utilisé sont le plus souvent :
Oracle, Teradata, DB2, SQL Server
Il y a aussi d'autre base a priori non relationnel :
Sybase IQ
CA-IDMS
Mais pas de trace de Pick !
Ne vous en déplaise, le modèle relationnel a largement fait ses preuves
même s'il reste encore de la place pour les autres modèles.
En fait, une conséquence de l'approche MV conduit a stocker de façon
physiquement proche un certain nombre de données relatives à un individus.
Par exemple, stocker plusieurs téléphones d'un individus est "près" du nom
et de l'adresse de cet individus. Dans de grandes base relationnelles que
j'ai occasion de gérer (100 Millions d'individus, milliard de records d'info
de gestion), il s'avère que les tables sont très grandes et que tout autre
accès est forcément "loin" sur le ou les disques et nécessite plusieurs
accès (index, puis data). Dans ce contexte, quand on lit quelques tables
autour d'un individus, il est clair qu'une approche MV sera probablement 10
fois moins coûteuse en temps d'I/O (toutes choses égales par ailleurs). On
limite un peu les dégâts en relationnel par des redondance dans le modèle
physique ou on remonte d'une table vers une table parent des info utilisées
massivement. On fait du tuning laborieux en jointures et index, mais ce
n'est qu'un replâtrage partiel qui limite un peu les dégâts : Il faut bouger
de nombreuses fois les têtes de lecture rien que pour collationner des
informations autour d'un seul individus! En caricaturant, les SGBDR ont la
"bêtise" de stocker les téléphones entre eux, les adresses entre elles, les
factures entre elles. Au lieu de stocker le téléphone près de
l'individus....
Aujourd'hui, nous arrivons à une telle complexité de système (100 aines de
tables, cardinalités élevés, par exemple si un individus n'a que 2-3
téléphones, il peut avoir des milliers de lignes d'articles achetés en
grande distribution...), que je crains qu'un MV serait autant débordé en
problèmes de ressource qu'un SGBDR. Pick à donné sa quintessence à une
époque qui correspondait à sont maximum d'efficacité potentielle : les
tables (au niveau conceptuel) se comptaient en une ou deux dizaines et non
en centaines, les enregistrements se comptaient en millions et non en 100
aines de millions. On peut aussi prêter au MV dont la performance peut être
supérieure dans certains contextes de nous apporter des idées pour améliorer
les performances des SGBDR :-)
Ceci étant dit, les assertions "s'obstiner dans l'erreur", "utiliser que des
jouets comme SGBD", me semblent tout à fait déplacées et indignes. C'est le
lots des groupes non modérés d'avoir parfois à traîner quelques boulets :-)
Jean-Francois BOITARD Wegener DM
> En fait, une conséquence de l'approche MV conduit a stocker de façon
> physiquement proche un certain nombre de données relatives à un individus.
> Par exemple, stocker plusieurs téléphones d'un individus est "près" du nom
> et de l'adresse de cet individus. Dans de grandes base relationnelles que
> j'ai occasion de gérer (100 Millions d'individus, milliard de records d'info
> de gestion), il s'avère que les tables sont très grandes et que tout autre
> accès est forcément "loin" sur le ou les disques et nécessite plusieurs
> accès (index, puis data). Dans ce contexte, quand on lit quelques tables
> autour d'un individus, il est clair qu'une approche MV sera probablement 10
> fois moins coûteuse en temps d'I/O (toutes choses égales par ailleurs). On
> limite un peu les dégâts en relationnel par des redondance dans le modèle
> physique ou on remonte d'une table vers une table parent des info utilisées
> massivement. On fait du tuning laborieux en jointures et index, mais ce
> n'est qu'un replâtrage partiel qui limite un peu les dégâts : Il faut bouger
> de nombreuses fois les têtes de lecture rien que pour collationner des
> informations autour d'un seul individus! En caricaturant, les SGBDR ont la
> "bêtise" de stocker les téléphones entre eux, les adresses entre elles, les
> factures entre elles. Au lieu de stocker le téléphone près de
> l'individus....
C'est aussi ce qu'on fait aujourd'hui sur les grosses bases
relationnelles. Par ex. les /multiple table hash clusters/ avec Oracle,
qui permettent de stocker sur des blocs physiquement proches des données
liées logiquement. (je suppose que les concurrents d'Oracle proposent
des choses similaires, mais je ne connais pa les termes utilisés).
> Ceci étant dit, les assertions "s'obstiner dans l'erreur", "utiliser que des
> jouets comme SGBD", me semblent tout à fait déplacées et indignes. C'est le
> lots des groupes non modérés d'avoir parfois à traîner quelques boulets :-)
Du moment qu'elles sont en charte, les contributions fausses ou
farfelues sont de toutes façons acceptées sur les groupes modérés.
Et ça présente l'avantage de mettre un peu d'animation, tout en faisant
ressortir des éléments intéresants : je n'avais plus entendu parlé de
Pick depuis de nombreuses années, et je l'imaginais aux oubliettes avec
Prologue.
--
Th. Thomas.
> effectivement mes expressions "s'obstiner dans l'erreur", et "utiliser que
> des jouets comme SGBD" sont exessif mais etait neccessaire pour focalise
> l'interet et surtout obliger a des recherches et forcer le debat par une
> polemique
Bref, je suis tombé dans un troll.
Quand on a aussi peu de scrupules avec la vérité, il n'y a pas de raison
de penser que le reste des affirmations soit de meilleur niveau.
Pour discuter, il faut être deux. Quand l'autre interlocuteur est
d'aussi mauvaise foi, qu'il balance des contre-vérités flagrantes en
permanence, il est préférable d'abandonner la discussion et de le
laisser dans son monologue.
Vous n'êtes même pas conscient que vous vous enfoncez à chaque nouveau
message.
comp.databases.informix : 256 messages
comp.databases.ms-sqlserver : 660 messages
comp.databases.oracle.server : > 1000 messages
et
comp.databases.pick : 144 messages
Il n'est clairement pas possible d'accorder la moindre confiance à vos
propos. Visiblement, vous êtes resté bloqué 20 années en arrière (comme
le montre les exemples ou le vocabulaire que vous employez).
helios a écrit:
> Bonjour,
>
[...]
>
> un SGBD Multivalue peux sur un simple Pc sous Linux ou Windaube gerer une
> base de 30000000 de fiches avec 500 utilisateurs et un temp de reponse
> normal
Dans un SGBD relationnel la notion de fiche n'existe pas. Seuls les concepts de
table, ligne et colonne existent, avec leurs attributs et opérateurs spécifiques.
La comparaison s'arrêt donc ici.
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
> "Bruno Jargot" a écrit dans le message de
> > Pour les plus grosses bases :
> > http://www.wintercorp.com/vldb/2003_TopTen_Survey/TopTenWinners.asp
> >
> >
> apparement ce site fait une erreur dans le cas de France Telecom car la base
> France TELECOM est sous UNIVERSE 9.2 (IBM) et est en cours de basculement
> UNIVERSE 10 , elle est compatible Oracle puisque universe sait faire du
> oracle mais c'est un systeme PICK ou alors il ont recenser une base
> marginale chez FT pourtant la taille de 29GO est correct (hors backup et
> securisation et replication)
Je comprends que 29 Go représente beaucoup pour PICK mais pour une base
Oracle, cela correspond à une petite base.
La base dont il s'agit dans ce recensement a une taille de 29 To.
> Les moteurs utilisé sont le plus souvent :
> > Oracle, Teradata, DB2, SQL Server
> >
> > Il y a aussi d'autre base a priori non relationnel :
> > Sybase IQ
> > CA-IDMS
Non CA-IDMS n'est pas relationnel :
http://database.ittoolbox.com/documents/document.asp?i=630
> Sybase IQ est relationnel
> pas de trace de la base de donnees de BT qui ferait 1,7To sous CA-IDMS
> (source CA-idms mais je doute de la taille) CA-IDMS relationnel
>
> > Mais pas de trace de Pick !
>
> apparement ce site ne recence que les bases relationnels
Ben non puisqu'il y a CA-IDMS.
Peut être que les entreprises qui ont des bases PICK importantes ont
honte de l'avouer ou alors, il n'y en a pas qui soient capables de
rentrer dans ce classement.
> IBM remplace progressivement sont parc DB2 par U2 (Universe Unidata)
> (systeme pick)
> U2 UNIVERSE / UNIDATA
Je suis allé voir sur le site d'IBM. C'est amusant, le mot relationnel
est abondamment mis en valeur. Et dire qu'IBM remplace DB2 par U2 n'est
qu'un mensonge de plus. Dans le meilleur des cas, IBM ajoute des
fonctionnalités de U2 dans DB2.
> moi j'ai comp.databases.pick : 565
> et ici 244
Vous ne vous rendez donc pas compte que vous comparez :
- un groupe francophone (ici)
avec
- un groupe international (comp.databases.pick) !
Votre comparaison n'a donc aucun sens vu la différence considérable
d'audience entre les deux groupes.
> comment s'appel un sgbd relationnel ayant les fonctionnalite de U2 ?
>
> cela s'appel un SGBD MV
>
> tout les sgbd Mv sont aussi relationnel puisque les MV peuvent faire du
> relationnel
>
> comme tout les anes sont des mamiferes
Vous racontez tellement d'aneries ...
Il est interressant de voir que vous ne répondez qu'à ce qui vous
arrange.
D'ailleurs votre nouvelle affirmation vient en contradiction avec votre
message initial où vous opposiez les SGBD relationnel avec les SGBD MV.
Maintenant, les SGBD MV sont aussi des SGBD relationnel. Mais vous avez
reconnu que vous aviez raconté n'importe quoi pour provoquer la
polémique.
> le remplacement de db2 par u2 est de source IBM pourquoi croyez vous ibm a
> acheter U2 ? pour faire joli?
Cela ne signifie pas forcément grand chose.
Pourquoi IBM a racheté Informix ? pour faire joli ?
Et non, IBM ne remplace pas db2 par u2.
> un SGBD MV est relationnel dans la mesure ou il est superieur au relationnel
Vous vous relisez ?
> si j'avais lancer le debat de maniere mooderer il y aurait eu aucune
> suite tandis que la plusieur personne m'ont contacte en prive suite a
> leur recherche et au debat (polemique) et elles vont prochainement
> travaille en PIck
Plonk, fait le mytho analphabète en touchant le fond de la boitakon.
Éric Masson
fu2: poubelle
--
Existe-t-il un numéro vert où ceux qui débuttent sur les forums du web
peuvent poser des questions ? Ce forum de conseils est très bien, mais
il serait bon de pouvoir discuter de vive voix avec des conaisseurs.
-+-Le <http://www.le-gnu.net>: Le club des connaisseurs de neuneux -+-
> ce n'est pas un troll ni de la mauvaise fois puisque j'admet avoir exagerer
> et reconnait les faits il y a juste un peu de provok au depart , si j'avais
> lancer le debat de maniere mooderer il y aurait eu aucune suite tandis que
> la plusieur personne m'ont contacte en prive suite a leur recherche et au
> debat (polemique) et elles vont prochainement travaille en PIck car il y
> trouve un interet que ne presente pas le sql et la est la reussite de ce
> debat car plusieurs personnes on decouvert une solution qui leur convient
Et on devrait vous croire, après toutes les conner^^ âneries que vous
avez sorti dans ce fil ?
> quand a ceux qui veulent a tout prix avoir raison et rejette les SGBD MV
> sans meme avoir cherche a savoir ce qu'ils sont c'est leur choix
Paille, poutre,.... Vous n'arrêtez pas de vous contredire à pratiquement
chaque message.
On va prendre un de vos exemples, des fois que ca vous aiderai à
comprendre : vous voulez avoir raison à tout prix sur les Harley, et
vous avouez vous même de mal connaitre les Solex...
> pour info le news comp.databases.pick (qui represente seulement les sgbd MV)
> a plus de deux fois plus de post que le present news, sans commentaire
> comprenne qui veux ce qui est a comprendre
Et encore une ânerie de plus, vous comparez un forum international et un
forum francophone, ca ne veut strictement rien dire.
--
Bruno BAGUETTE - bou...@alussinan.org
mais y a des jointures et tout ca dans un base MV?
des contraintes d'intégrité?
des transactions?
parce que tes exemples se limitent toujours à une seul table !
Pour l'instant j'avoue que pour moi ca reste un moteur d'indexation plus
qu'autre chose...
A un moment j'ai essayer d'indexer avex swish-e l'annuaire de france
telelcom.
ben j'ai mis plusieurs heures a l'indéxer, mais la recherche était quasi
instantanée... ce qui est bien normal !!!
Etienne
> merci a ceux qui
>
> - ont ete inteligent pour se renseigner
> - qui ont compris
> - qui ont fait progresser le sujet
Vu comment le sujet a été introduit que ce soit dans le fond comme sur la forme,
c'était loin d'être évident !
> quant a certain ane qui font de l'obcurantisme
> ceux qui tronque les reponses
> ceux qui sorte du sujet du forum
Il aurait alors fallu aborder le sujet d'une manière moins provocatrice que tu
ne l'as fait, et ne pas employer une prose s'apparentant plus à un collégien en
mal de "troll" qu'à une personne diplomée "bac + 8" avec 20 ans d'expériences
mais dont paradoxalement les connaissances SQL sont limites (sic) !
> ils ont simplement parasite le debat par incapacite d'evolution
Ton débat ne pouvait être que stérile vu la manière dont tu y es pris et tes
digressions ultérieures ont fini de te décrédibiliser complètement !!!
> les faits resteront les faits et quoi qu'ils disent ou fassent ils ne
> changeront rien a la realite
Ceci n'est malheureusement qu'une assertion non argumentée...
> "le singe qui ne peut attrapper un fruit dis qu'il est trop vert"
Et la vérité n'est pas aussi binaire que tu le prétends...
> le sgbd Mv est un progres par rapport au relationnel mais tout le monde n'en
> as pas besoin
> mais pourquoi avoir une tv nb quand ont peux en avoir une couleur
cf. ci-avant...
--
Philippe.
Bac + 8 et 3 fautes d'orthographe et de grammaire par phrase... j'ai des
doutes sur la qualité de l'enseignement.
--
Steph.K
http://www.acces-pour-tous.net
<troll>
Désolé mais je ne peux m'empecher de répondre, un défis dont les régles
sont définie par une partie n'est pas très honnête. Il aurait fallu
qu'un personne tierce et objective définisse les termes du défis, non?
(C'est juste une question pour faire avancer le schmilblick)
Et puis le problème de Lola n'est pas du tout d'avoir une solution clé
en main, et payante en plus. Il demande simplement d'établir un modèle
de données correspondant à son besoin, et comme en plus il utilise
postgresql visiblement il recherche une solution gratuite.
</troll>
Lola le plus simple et de raisonner en terme d'objets et d'attributs
(facilement convertible en terme d'entité et de relation). Tu peux
facilement déterminé les objets (album, compositeur, chef, renre,
artiste, morceau, etc...) et leurs attributs (un album à une date de
sortie, un titre, .... Un artiste à un nom, des prénoms, etc...) et
enfin les relations entre eux (un album est produit par une maison
d'édition, un compositeur a composé tel morceau de musique).
Tu peux faire ça sur un bout de papier assez simplement ou utiliser des
outils informatique pour le faire.
Cordialement
helios a écrit :
> "Lola" <lol...@wanadoo.fr> a écrit dans le message de
> news:20050626220...@mbv.interlud.com...
>
>>Bonsoir,
>>
>>je suis devant un pb de conception de base.
>>Il me faudrai créer une BD tournant sous Postgresql
>>destinée à référencer un discothèque de musique
>>(classique à 95%), et je vois pas trop comment
>>m'y prendre. Faut-il faire une seule table (simple
>>dans ce cas, mais délicat pour les requêtes) ou
>>plusieurs tables ?
>>
>>En gros il y aurait les "colonnes" suivantes :
>>compositeur, artiste, titre, genre, chef, orchestre/choeur,
>>soliste1 à soliste10 (opera oblige...), éditeur, date enregistrement,
>>date édition, commentaire.
>>
>>Si vous avez des idées/liens, etc. Merci d'avance.
>>
>>PS. Il ne s'agit que d'une petite base de quelques milliers
>>d'enregistrements et d'un usage non professionnel mais plutôt
>>associatif.
>>--
>>L.G
>>
>
>
>
> moi je proposes un defis a Bruno puisqu' il soutient que les SGBD MV ne sont
> pas terrible
>
>
> lui et moi on realise le projet de Lola (bd miusique) et on compare
>
> voici le cahier des charges techniques que je propose et la methode
> d'evaluation
>
>
> le system avec toute la doc necessaire au devellopement
> + la base de donne (estime) de 1000 morceaux (on entre dix morceaux tire au
> sort dans la liste des 1000 et on multiplie par 100 la taille entre la base
> 0 morceau et la base 10)
> + un programme de terminal distant (style accuterm, winnix, wintergrate
> .......)
> le tout devra tenir dans 16MO
>
> l'utilisateur feras ses interrogations en Francais et qu'en Francais
> (apprendre l'anglais est trop long)
>
> le temps de saisie de la base de 1000 morceau sera calcule en multipliant
> par 100 le temp de saisie de 10 morceau a partir d'une base de 0 morceau
>
> la realisation devra pouvoir exporter et importer ses fichiers en format
> DBF, XLS ,TXT et CVS
>
> le prix de l'ensemble logiciel (base de donne + terminal distant ) devras
> etre au plus de 100 euro HT
>
> aucune doc papier ou exterieur admise
>
> methode de comparaisons :
>
> (taillebase donnees de 1000 morceau) * (temp realisation en minute) * (temp
> saisie 1000 morceau)
>
> le score le plus bas a gagne
>
> sont eliminatoire:
> - le depassement des 16mo pour le total
> - budget de licence superieur a 100 euro ht
> - temp develloppement superieur a 4H
> - interrogation ayant recourt a des termes anglais
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Concernant le défis, helios va probablement utiliser le rad qui doit se
trouver dans son sous système, d'ou un temps de développement quasi nul.
S'il veut jouer à ça avec ses petites volumétries, on peut mettre un
face du windev/webdev qui intègre également sa propre base de données...
A ma connaissance, c'est le plus rapide/intuitif/complet... quand on
veut faire du rad.
Kermabon Stéphane a écrit :
helios a écrit :
> j'utiliserais pas de rad mais si windev rentre dans le budjet et la taille
> inferieur a 16mo au total utilise le
> (windev me semble valoir plus de 100 euro en kit develloppeur et faire plus
> de 16mo)
> ou alors ont peux meme interdire les rad et gui
>
> cela sens de plus en plus la defilade c'est au pied du mur ......
>
> tout les docs et outil doivent etre fourni dans les 16mo et 100euro ht
>
> seul est preinstalle windows et acrobat reader et openoffice eventuellement
> rien d'autre
>
> et j'accepte tout condition supplementaire que peut impose le monde
> relationnel si eux peuvent le faire :
>
> par exemple pouvoir aussi interroger la base en allemand en italien et en
> espagnol et russe 4h plus tard
> (usage d'un traducteur internet autorise pour effectuer les traduction lors
> de la creation et fonctionnement offligne apres limite 16mo restant de mise)
>
>
>
>
>
>
>
> "Hugues" <hugues_...@yahoo.fr> a écrit dans le message de
> news:42bffd06$0$6393$626a...@news.free.fr...
> Le seul problème, c'est que tu ne sais pas lire.
Oui et vous vous ne savez pas répondre. 4 lignes au dessus de 185, c'est
de l'abus.
> La problèméatique
> initiale concerne de l'assistance pour créer le modèle de données sous
> posgresql...
Voilà : soit il répond à question posée soit il ferme sa gueule.
> Donc tu pollue le forum (mais je ne suis pas le premier à
> le constater)
Vous aussi vous polluez en répondant au dessus du message intégral de ce
blaireau : merci de répondre sous les citations et de couper ce qui
n'est nécessaire à la compréhension de votre réponse.
--
Patrick Texier
Tous les résultats de GP F1 librement téléchargeables
http://www.genindre.org/perso/f1.htm
On Mon, 27 Jun 2005 13:24:37 +0200, helios <helios....@free.fr> wrote:
> sont eliminatoire:
> - le depassement des 16mo pour le total
> - budget de licence superieur a 100 euro ht
> - temp develloppement superieur a 4H
> - interrogation ayant recourt a des termes anglais
Allez, moi je propose un défi alternatif:
- le budget de license est de 0
- les sources doivent être disponibles
- on doit pouvoir trouver des gens compétents sur le sujet facilement
- il doit déjà exister des interfaces pour perl, php, python, Java, C/C++,
et tout le tintouin
- ça doit utiliser un langage d'interrogation normalisé et portable
Je ne dis pas que ton machin c'est pas bien, je dis juste que ça ne
correspond pas forcément aux besoins de chacun. Si quelqu'un est content
avec un SGBD SQL, pas besoin de le pousser à tout prix vers ton bidule qui
est payant, pour lequel il n'y a pratiquement personne qui pourra assister
la pauvre victime, qui n'est pas forcément interfaçable avec le langage de
son choix (ben oui, les applications de BDD stand-alone, c'est amusant
deux minutes, mais c'est quand même pas le but du jeu ici), et avec lequel
on est coincé si jamais on a un problème parce qu'il n'y a pas d'autre
système compatible, même de loin.
EOT.
Jacques.
et qu'on utilise les champs
idcontrib
idcontribpere
sujet
date
auteur
contenu
et qu'on teste effectivement les performance des différentes solutions.
personellement, je veux bien faire la solution swish-e qui consiste à
indéxer tous ça et faire des recherche dedans.
apres on fait des requetes du genre
- trouver les contributions de helios
- trouver les réponses au contributions de helios qui ne sont pas de lui
- nombre de contributions par sujet proposé par helios
- nombre de contribtion de helios
- nombre de contribution par auteur
- liste des contributions ecrite entre le 01/01/2004 et le 15/06/2004
- liste des contributions ecrite entre le 01/01/2004 et le 15/06/2004
n'ayant pas eu de réponse.
- classement des contributeur en fonction du nombre de contribution
- liste des sujet et profondeur de la réponse (en niveau de Re:Re:... vous
m'avez compris)
voila.
ca peut etre interessant de tester...
bien evidement, il faudra prevoir une interface pour pouvoir modifier une ou
plusieurs contribution afin de juger la capacité du SGBD à être mis a jour
!!!
si on trouve 4 participants
- postgreSQL ou MySQL (base libre)
- oracle (base payante)
- swish-e (moteur d'indexation)
- base MV
ben moi ja veux bien me frapper le code pour swish-e !!!!
Ca tente quelqu'un?
ca pourrait être sympa. ca prendra pas trop de temps, et puis au moins on
sera fixé.
Etienne
> Lola le plus simple et de raisonner en terme d'objets et d'attributs
> (facilement convertible en terme d'entité et de relation). Tu peux
> facilement déterminé les objets (album, compositeur, chef, renre,
> artiste, morceau, etc...) et leurs attributs (un album à une date de
> sortie, un titre, .... Un artiste à un nom, des prénoms, etc...) et
> enfin les relations entre eux (un album est produit par une maison
> d'édition, un compositeur a composé tel morceau de musique).
Ben, le pb c'est que c'est une BD sur de la musique classique.
Donc :
si dans certaines entités on a bien des clefs uniques par le nom
par exemple pour les compositeurs, chefs, solistes, ce n'est plus le
cas pour les orchestres (souvent les mêmes dans ce milieu), les titres
d'oeuvres (le terme symphonie revient très souvent...), etc.
Le but premier de la BD est de savoir quel chef ou soliste a dirigé/
chanté/joué quoi, avec qui, quel orchestre, à quel endroit à quelle date
et est-ce édité (pas toujours le cas pour les inédits) chez qui.
Et tout ceci dans tous les sens au niveau requête.
Pour répondre à Pif, quand je disais «pas très fin» ça voulait dire :
- j'arrive à retrouver ce que je cherche mais c'est noyé dans d'autres
données qui correspondent à mes requêtes. C'est pour cela qu'en faisant
plusieurs tables je pensais "affiner" la recherche.
Il faut absolument que ma requête affiche tout sur une même page et non
fiche par fiche. Sinon ce serai trop simple... :)
> Tu peux faire ça sur un bout de papier assez simplement ou utiliser
> des outils informatique pour le faire.
Justement c'est pas simple, en tous cas pour moi. :(
Merci.