Jump to content

Spidetra

Hubmaster
  • Content Count

    326
  • Joined

  • Last visited

Everything posted by Spidetra

  1. C'est quoi cette info ? Tu couple le SGBD que tu veux avec IIS. Pour MSDE, c'est effectivement une version gratuite. Cette version sert en développement, mais surtout pas en production.
  2. Si tu veux réussir une migration d'un SGDB vers un autre, il faut l'anticiper. 1. Commence par modéliser tes bases de données. Passe par un outil comme PowerAMC 12, tu as une période d'éssai de 15 jours. MCD->MPD-> Génération de script de DB. N'hésite pas à générer des scripts pour +sieurs SGBD : mySQL, postgreSQL, SqlServer, Oracle, DB2, etc.... Garde les au chaud, on sait jamais. Si ton service explose et que tu as besoin d'un oracle 1. Bis Dans la mesure du possible, n'utilise aucune syntaxe SQL spécifique à un SGBD donné. Plus tu seras proche des standard SQL, plus la migration sera facile. 2. Découpe ton application en couche logique : dao/métier/présentation. Dans ta couche dao tu vas implémenter les fonctions ( ou objet ) d'accés aux données. tu auras une arbo du style : dao/mysql/*.php dao/pgsql/*.php dao/oracle/*.php etc... Ta couche métier fera appel aux fonctions/objet de ta couche dao sans jamais savoir quel est le mode de stockage derrière. Si tu réussis bien cette séparation, changer de SGBD reviendrat à réecrire une couche dao. Dans ton cas, tu n'as peut-être pas intérêt à passer par des outils d'abstraction d'accés aux SGBD ( style PEAR :: DB ). Ces outils sont géniaux pour te simplifier l'accés aux DB, par contre tu vas perdre en terme de performance. Dans un fichier Include tu définis ton path vers la bonne couche DAO. En théorie, la migration d'un SGBD consistera juste à modifier ce path. En théorie . 2. Bis Il faudrat prévoir des scripts de migration de données. ça devrait pas être le plus dur. 3. Ta couche métier. Pour simplifier la migration d'un SGBD vers un autre tu as tout intérêt a implémenter ta logique métier en dehors du SGBD. En clair : transférer les éventuelles procédures stockées du SGBD vers ta couche métier. Je suis pas tjrs d'accord avec ce point. Les procédures stockées ont l'avantages d'être plus performantes. ça c'est à voir en fct de ton projet et de tes habitudes de devs. 4 Optimisation des performances : Pour la mise en place d'un outil statistique tu as tout intérêt à séparer le stockage de tes données dans deux bases séparées : - Premiere base ( DBLog ) : la base de recueil des informations - Deuxième base ( DBStat ) : la base de consolidation des données. Cette séparation te permettra, le jour où tu en auras besoin, de mettre tes deux bases sur deux serveurs différents, sans trop de pb. Ces deux bases ont des spécificités totalement opposées : - DBLog : sera quasi exclusivement en écriture - DB Stats : sera quasi exclusivement en lecture - DBLog : Tu ne met aucun index sur cette base. Les index améliorent les performances des SELECT. Ils ralentissent les opérations d'INSERT et d'UPDATE. - DBStat : Tu use et abuse des index dans cette base pour optimiser les opérations de lectures. DBLog sert à recueillir les stats en temps réels. Chaque nuit tu passes tes scripts de consolidation qui vont transférer les données de DBLog vers DBStats. Chaque matin tes clients auront leurs stats dispo. 5. Quelle solution de stockage Petite réflexion perso : Est-ce qu'un SGBD est la meilleure solution de stockage pour un outil statistique ? Les SGBD sont performant sur des modèles de données relationnes ? Les statistiques sont-elles des données relationnelles ? La phase de consolidation dans un SGBD => Ok, cela pourrait simplifier l'implémentation du projet. La phase de Log => Est-ce qu'un SGBD est vraiment la structure la plus performante pour logger des stats ? Est-ce qu'un système de fichier ne serait pas plus performant ? Comment font xiti, eStat et les autres pour recueillir leurs données ?
  3. Très honnêtement, si ton projet devient important, un forum n'est pas le meilleur endroit pour choisir un SGBD. Il va falloir que tu fasses une liste de ce qui est important pour toi, et comparer les différents outils du marchés. Je connais assez bien les SGBD mais je me risquerai certainement pas à te conseiller tel ou tel produit.
  4. create table IF NOT EXISTS foo ( bar varchar(32));
  5. C'est Sun qui va être content ! J'avais tjrs considéré l'argument "Eco-Responsable" de Sun avec ces UltraSparc comme un bel argument marketing. On voit bien avec ces pb à répétitions que ces serveurs "4 core" "basse-consommation", vont représenter des alternatives intéressantes pour les DataCenter
  6. pour mysql tu vas utiliser un outil comme mysqlWorkBench qui va te permettre de faire du reverse engeneering a partir de ta DB
  7. Je ne comprend pas le sens de ta clé primaire id, id2 ? Ta table test est lié avec d'autres tables ?
  8. C'est quoi la structure exacte de ta ta ble ? Une clé primaire est obligatoirement unique. Elle identifie de façon non ambigue un enregistrement de ta table. UNIQUE est une contrainte que tu peux ajouter à n'importe quelle colonne de tes tables. Ex : Tu pourrais décider de donner la caractéristique UNIQUE à un champ qui contiendrait des e-mails, un N° de sécurité sociale, la plaque d'immatriculation d'une voiture, etc...
  9. Merci DuDu. J'avais oublié le nom de ce .js et je recherchais désespérement cette référence depuis des semaines.
  10. Le champ Id, ce n'est pas la clé primaire de ta table ? Si c'est bien le cas tu doit avoir des relations entre ce champ et les autres tables de ta base. C'est pour cette raison que tout le monde t'as conseillé de ne pas y toucher manuellement. Maintenant si c'est un champ classique, rien ne t'interdit de modifier ses valeurs.
  11. La même requête en plus simple ( J'ai honte ) SELECT DISTINCT (v1.IDVilla + 1) As IDLibre FROM villa v1, villa v2 WHERE v1.IDVilla < v2.IDVilla AND v2.IDVilla >= ( 2 + v1.IDVilla ) AND NOT EXISTS ( SELECT * FROM villa v3 WHERE v3.IDVILLA > v1.IDVilla AND v3.IDVilla < v2.IDVilla ) Les modifications : 1. La table v3 servait à rien dans le premier SELECT 2. S'il existe un INDEX sur la séquence testée, cette syntaxe sera plus performante : v2.IDVilla >= ( 2 + v1.IDVilla ) au lieu de ( v2.IDVilla - v1.IDVilla ) >= 2 Cela forcera l'utilisation de l'index sur v2.IDVilla. Si le champ n'est pas un champ indexé les deux syntaxes sont équivalentes
  12. 1. Je partage l'avis général sur les manipulations de clé primaire. 2. Je poste une solution permettant de trouver les trous dans une séquence. Cette séquence peut-être une clé primaire ou n'importe quel autre type de séquence 3. J'ai trouvé la requête par tatonnement. Donc, il existe certainement une meilleure solution. 4. La requête n'est pas parfaite. Elle marche très bien pour les trous de longueur 1. Si la longueur est > 1, la requête ne trouve que le premier élément de la séquence manquante. Dans mon jeu de test il manque : 6, 7, 15, 16. La requête retourne uniquement 6 et 15. Il est donc possible : - de réutiliser les n° 6 et 15 - de repasser une 2° fois la requête qui retournera 7 et 16. 5. Je suis preneur de toutes modifications permettant d'améliorer cette requête. 6. SGBD ne supportant les requêtes imbriquées s'abstenir Mon jeu de test : IDVilla Prix 1 10 2 10 3 10 4 10 5 10 8 20 9 20 10 20 11 30 12 30 13 30 14 30 17 30 18 40 19 40 La requête : SELECT DISTINCT (v1.IDVilla + 1) As IDLibre FROM villa v1, villa v2, villa v3 WHERE v1.IDVilla < v2.IDVilla AND ( v2.IDVilla - v1.IDVilla ) >= 2 AND v3.IDVIlla BETWEEN v1.IDVilla AND v2.IDVilla AND NOT EXISTS ( SELECT * FROM villa v4 WHERE v4.IDVILLA > v1.IDVilla AND v4.IDVilla < v2.IDVilla )
  13. si tu poste la structure de tes 2 tables ( c'est simple avec phpMyAdmin ) et un jeu de test. J'essayerai de me pencher sur ta requête ( pas ce soir ) Faudrat bien qu'un jour ces hébergeurs fassent un peu évoluer leurs versions de mysql
  14. Je donne cette réponse suite à une demande par MP. Je ne veux pas fournir d'exemple public. Comme toujours, chaque expérience est un cas particulier. A titre perso, je suis très favorable à l'utilisation de domaines séparés et de sous-domaines. Je rappelle que je ne cherche ni à convaincre, ni à argumenter. Je ne fais que répondre à une demande. 1. Du point de vue du référencement : Nous avons ré-organiser l'architecture de notre site web avec une langue => un nom de domaine. Nous avions une vingtaine de langues. Résultat Google : 400% d'augmentation du trafic, positionner sur des requêtes plus pertinentes. Les résultats ont été excellents sur certains pays d'Europe de Nord ( Danemark, Norvège, Suède, Pays-Bas ). Notre principal concurrent a fait exactement le choix inverse avec des résultats aussi excellents, voire même meilleur. Conclusion : Match Null. Chacun pourras trouver un exemple ou un contre-exemple pour argumenter sa position. 2. Il n'y a pas que le référencement dans la vie Je suis très favorable à la séparation d'un site en NDD ou sous-domaine différents car c'est un moyen très simple, très économique, ne demandant aucune compétences techniques particulières pour faire face à une montée en charge d'un site web. Soit vous allez voir votre PDG en lui disant : - Bonjour, nous avons un pb de montée en charge. Nous devons mettre en place un cluster linux, du load-balancing, du round-robin DNS, externaliser notre système de cache auprès d'Akamai. Ha, oui au fait, il faudrait aussi embaucher un administrateur système pour s'occuper de tout ça ! Soit cous avez anticiper la montée en charge, sans savoir si vous en aurez besoin un jour : - image.example.com : le host qui héberge toutes les images - pdf.example.com : le host qui héberge tout les pdf - ads.example.com : le host qui héberge votre serveur de banière - etc..... Tout ces hosts peuvent très bien être hébergé sur le même serveur. Le jour ou vous avez une montée en charge, il vous suffit de prendre un serveur dédié chez OVH. Vous transférez vos images, vos pdf, votre serveur de bannière sur ce nouveau serveur. Un petit coup de DNS. Et tout fonctionne sans avoir besoin de faire appel à des techniques compliqués. Ensuite, vous laissez vos pays principaux sur votre serveur principal. Vous déplacez tout vos petits pays vers un serveur secondaire. Nous avons fait face à la montée en charge avec des solutions très simple et très économique. Si tout notre site avait été installé sur un seul host, les différentes migrations nous auraient coûté plus cher. Je ne dis pas : il faut absolument organiser un site web en domaines et sous-domaines. Je dis juste : chacun fait comme il veut en fonction des ses propres expériences.
  15. Lorsque j'ai beaucoup d'état à gérer comme ça, je priviligie les opérateurs sur les bits. Il y a un article complet sur le hub sur cette méthode Les techniques de bit hashing http://www.webmaster-hub.com/publication/article75.html Au lieu d'avoir : code_recherche| identification_id --------------------------------------- 1 |1 1 |2 1 |3 --------------------------------------- 2 |2 2 |3 2 |7 --------------------------------------- J'aurai une seule ligne par identification_id et code recherche correspond à un masque binaire entre les différentes valeurs possible. Ta requête pourrait être du style : SELECT * from tab_recherche WHERE code_recherche = ( CODE_1 & CODE_2 & CODE_3 & etc... ) cela simplifie la requete et la gestion. Par contre du coup il faut que tu réorganise totalement ta table.
  16. Tu as aussi cette syntaxe en utilisant des alias. Attention : cette syntaxe marche avec mySQL, elle ne marche pas avec tout les SGBD. SELECT f.foo, f.bar, (f.foo/f.bar) as quotient FROM foo f order by quotient;
  17. Ok, salut à tous. ça vient de revenir et je découvre la discussion. C'est pas tombé d'un coup. Des sites sont devenus innaccessible petit à petit. Je vote aussi pour un ob DNS qques part et rupture des routes.
  18. Doit y avoir un pb quelque part, j'accède au hub, mais quasiment plus à aucun autre site !
  19. J'ai de plus en plus de sites qui deviennent innaccessible dont Google France et .com Vous avez le même problème ? Redbus ? Mon FAI ?
  20. A mon époque la filière S était divisée en Bac C et Bac D. C'est toujours le cas ? La fillière D était accessible ( fallait bosser quand même )
  21. Dan a raison. - Commence d'abord par le Bac. Je connais pas les nouvelles filières. A mon époque c'était C, D et peut-être H ( Bac Informatique ? ). - Ensuite, il faut au moins être à Bac+3 ( nouvelle norme européenne, un bac+2 n'est plus suffisant ). Les filières sont nombreuses mais tu peux, par exemple, commencer par un DUT ou un BTS ( bac + 2 ) après ton Bac. Les fillières DUT ou BTS, sont des fillières sur dossier. Il faudrat donc avoir un bon niveau au Bac et un bon dossier scolaire en général. L'école est une contrainte aujourd'hui. Si tu abandonnes tu vas le regretter toute ta vie. Laisse tomber les formations payantes et chères qui débouchent souvent sur une impasse. Le seules études qui comptent sont celles qui sont reconnus pas l'éducation nationale et par les entreprises.
  22. _AT_TheRec : On est globalement sur la même longueur d'onde. Il est vrai que les chaque cas est spécifique. Tu as tout résumé en une phrase :
  23. Juste pour info, j'ai édité mon message sur le thread de Sébastien : "Juste une mise au point", à sa demande personnelle par MP, histoire de ne pas déshameçonné le poisson trop tôt. C'est quand même son post, plus que le post initial, qui m'a fait douter pendant quelques minutes. Enlever le statut de Modo de Sébastien, ça c'était du grand art
  24. Je suis tout de même surpris ( et déçu ) par la mise au point de Sébastien.
  25. Comme le poisson d'Avril d'OA à l'air d'avoir du succés, je met permet de faire ici, la copie d'un post du 10 janvier que j'avais fait sur un autre forum ( et dans le même style ). le post original -wri/forums/viewtopic_43262.htm
×
×
  • Create New...