robinsonvendredi

Oui http://www.mysql.com/oem/licensing.html

D'accord avec beal, les limitations en termes de charge dépendent surtout du serveur. Le choix de mysql est le plus répandu compte tenu de sa simplicité. Il existe de nombreuses autres bases de données telles que Postgres , MAX DB (par mysql), SQL server, IBM DB2 ,Oracle, Firebird, qui correspondent à des besoins différents, plus de possibilités SQL, support de java, XML, etc... SQl server et Oracle sont gratuites sur des serveurs mono processeurs, DB2 est gratuite sur un biprocesseur, avec les droits de redistribution compris pour SQL server et DB2 (je ne suis pas sûr pour Oracle). Si ton besoin dépasse les possibilités d'un bi-processeur, maxdb est un choix intéressant. Toutefois : - mysql et maxdb sont Open source mais les droits de redistribution sont payants. - maxdb, Postgrès et firebird sont Open source mais moins utilisées que les autres ce qui peut poser un problème de maintenance.

De mon point de vue tu as de bonnes chances de faire des ventes. Les moteurs de recherche de l'Internet ont un avantage marketing sur tous les autres supports : ils permettent de commercialiser à peu de frais un produit rare qui s'adresse à très peu de personnes. Donc c'est idéal pour les collectionneurs. Les 2 points les plus importants : - il faut que tu arrives à bien te référencer - une traduction de ton site en anglais voire en d'autres langues serait un plus Essaye aussi de vendre tes produits sur ebay.com

Merci !

Dan Peux tu préciser à un béotien comme moi pourquoi le RAID 1 soft est à déconseiller ? Est ce qu'il peut pose problème en cas de crash d'un des 2 disques durs ? Merci d'avance...

En ce qui me concerne j'envisage de louer un dédié chez OVH (distrib windows) pour proposer des démos en ligne d'un logiciel, héberger certains utilisateurs de ce logiciel, ainsi que pour un site qui demande des options incompatibles avec mon hébergeur actuel : filtre ISAPI (et oui je suis en MS), paiement en ligne, etc...le site étant prometteur en termes de volume. Merci pour les infos données par Dan et les autres. Y a -t-il parmi vous des connaisseurs des distrib Windows chez OVH, avec des conseils pour un débutant comme moi souhaitant se lancer dans un dédié ? Merci d'avance.

Bshop merci de l'honneur que tu me fais de me citer, je ne suis qu'un indépendant passionné !... C'est vrai que ce domaine demande beaucoup d'investissements, en temps et en efforts, et chaque projet relève au moins en partie sur des prestations sur-mesure... Donc je renouvelle mes encouragements aux nouveaux qui se lancent !

C'est le même principe que je connais , il existe un composant COM à installer sur le serveur qui utilise un fichier de licence avec une clé d'identification. Mais c'est transparent pour le développeur. Je trouve étrange qu'on t'oblige à gérer le SSL, ça signifie que la sécurité des données bancaires repose sur ton propre certificat ssl...es tu bien sûr que la doc ne fait pas référence au SSL comme technique qu'ils utilisent eux-mêmes pour sécuriser le paiement ? Autrement, d'après ce que tu dis ça ne correspond à rien de ce que je connais, désolé !!

Je ne suis pas tout à fait d'accord avec votre analyse. Les stocks et la comptabilité sont 2 notions distinctes : l'impact de la variation des stocks dans la comptabilité se mesure généralement une fois par an, à l'occasion de l'inventaire. En revanche, il faut de toute manière protéger les données confidentielles telles que le fichier client, qui réside forcément sur la base de données web. La plupart des données de gestion comme les stocks doivent être idéalement identiques sur le site et dans le logiciel de gestion de l'entreprise, ou tout au moins avec une bonne fréquence de synchronisation. En effet entre deux synchros vous risquez de traiter des données incorrectes. Le problème de synchronisation est double : 1. pouvoir accéder aux données de la base de gestion sans la "vriller" (en pratique ceci requiert version des logiciels sur bases de données SQL server ou Oracle) 2. bien comprendre la structure d'un logiciel de gestion, par exemple l'importation d'une commande peut impacter de nombreuses tables. Bon courage !!

Tu mentionnes un "fichier C" que je ne connais pas - je te donnes les indications suivantes, sous réserves qu'elles correspondent bien à ton système... Je suis étonné que tu cryptes en SSL l'envoi de données. En principe il n'y a dans les variables envoyées que des infos du type No de commande, montant de la commande, devise de paiement, etc...donc rien de confidentiel. C'est le serveur de la banque qui réalise le cryptage de la carte, du nom etc, sur un formulaire qui tourne sur le serveur de la banque et non pas sur le tien. Dans le message en retour tu récupères l'ID de la commande qui te permet de faire le traitement des données en local. La banque doit t'avoir transmis une documentation avec des fichiers-type qui correspondent au langage que tu utilises. Vérifie que la doc correspond bien à la version du logiciel installé sur ton serveur. Vérifie chaque variable passée au serveur de la banque avec ta doc. Si tes variables sont cryptées, elles ne sont pas récupérées correctement AMHA.

AMHA c'est au contraire la solution de paiement en ligne la plus répandue (http://www.sips.atosorigin.com/references/index.htm), auparavant utilisée par CIC avant la transformation en HSBC.

Dans ce cas enveloppe ta requete dans une procédure stockée, le plan de requête sera pré-compilé et tu auras de meilleurs résultats. A ta place j'utiliserai aussi une table temporaire pour éviter les jointures multiples : 1.Création de la table temporaire : SELECT DISTINCT p1.id_produit, p1.reference, p1.date_parution....INTO #stack 2.Suppression des lignes correspondant à la sous-requête 1 3.Suppression des lignes correspondant à la sous-requête 2 C'est un peu le même principe que la solution de Portekoi mais en restant en SQL

Pour juger des compétences de quelqu'un, il faut être plus qualifié que lui. La profession d'expert comptable est contrôlée par un diplôme d'Etat de niveau doctorat (bac + 8), plutôt difficile à obtenir. Si vous ne comprenez pas tout ce que vous dit votre médecin, votre notaire, votre avocat ou votre expert comptable, il faut lui redemander des explications. Vous ne savez pas mieux que lui ce qu'est une grippe, une hypothèque , un emprunt bancaire, etc... Peut-être s'est-il mal fait comprendre ? ca peut arriver.

Je confirme les propos de bshop, les logiciels e-commerce les plus courants ne sont pas orientés gestion. Seuls certaines SSII ou développeurs indépendants ont intégré cette approche, sachant qu'elle concerne plutôt le B2B (grilles de tarif, multi-échéances, etc...). En principe elle ne vous concerne pas (ou peu) si vous faites de la vente aux particuliers. Au niveau de la facturation, l'option la plus simple est de générer des journaux comptables à partir des factures, en effet les écritures comptables dans un format texte sont facilement importées dans Ciel comptabilité, avec création des comptes des tiers lors de l'importation. Par ailleurs, les fichiers nécessaires de Ciel compta : Plans de compte , Taux de taxe et journaux sont facilement accessible par une appli e-commerce. Si votre besoin porte uniquement sur la transformation de factures B2C en écritures comptables, il ne s'agit pas d'un développement très lourd.

Les moteurs de recherche évolués pour le e-commerce utilisent une indexation par mot-clé. La structure catégorie > famille > produit n'est pas rigide, on peut très bien entrer sur un groupe de mots clés, selon sa sélection être redirigé vers un autre groupe, ainsi de suite. C'est une technique très connue depuis longtemps (notamment dans le domaine de la gestion électronique de documents). C'est pas révolutionnaire...

Il faut malgré tout un capital "suffisant" (estime le avec ton expert comptable), car une société doit pouvoir faire face à des déficits en début d'activité. .

Bonjour, Le seuil que vous allez dépasser vous contraint à changer de régime fiscal, mais pas de régime juridique. Toutefois, je vous conseille de le faire, car juridiquement, une association qui n'est pas encadrée par un contrat de société est dangereuse : sans un contrat de société, les actes fait par l'autre associé vous engagent vis à vis des tiers, solidairement et indéfiniment. On dit que les actes des associés sont "inopposables aux tiers", c'est à dire qu'ils peuvent se retourner contre l'un de vous deux personnellement. En clair, vous pourriez être responsable sur vos biens propres des dettes de votre associé, pour peu qu'il présente son activité comme commune avec la vôtre. Sachez qu'une société a un coût : - coût juridique de constitution (bien que l'enregistrement au Greffe ne coûte plus grand chose, il reste à financer les honoraires d'expert comptable ou de conseil juridique). - coût des formalités récurrentes (rédaction des PV, enregistrements des actes et des comptes, etc...). Hormis ce coût, il n'y a que des avantages. La forme juridique qui me semble la plus appropriée à votre activité est la SARL. Je ne peux que vous féliciter sur votre intention de consulter un expert comptable. Il vous apportera une solution adaptée à votre cas particulier.

Voici une information sur ce thème : http://www-sop.inria.fr/axis/

Franchement, je ne pense pas que tu arriveras à mettre à défaut php / mysql sur le terrain de la performance. Pour les très gros sites, d'après mes modestes connaissances il y a une forte prédominance de serveurs websphere et oracle en java. Oracle est la base de données la plus utilisée. En effet le couple java/oracle et est le plus répandu dans les grandes entreprises, donc souvent, cette techno l'emporte pour les sites internet (par ex le site de la sncf est fait dans cette techno me semble-t-il). Pour les mêmes raisons, .NET est parfois choisi (Dell) Si tu t'adresses à des PME et que tes développements doivent être intégrés, .NET peut être un choix intéressant. Sinon php / mysql est le plus indiqué AMHA

Bonjour A mon avis ce que tu demandes n'est pas exactement de la gestion de stocks = les fournitures de bureau dans une entreprise ne sont pas considérées comme des fournitures stockées mais comme des consommables (sauf dans les papeteries dont c'est le métier de revendre ces fournitures). En termes plus concrets il va être difficile pour toi de tenir le compte des fournitures qui "sortent" des stocks, à moins d'obliger le personnel à noter scrupuleusement que leur gomme est usée ou leur ramette de papier terminée... Il me semble que ce que tu recherches est une gestion des achats et non une gestion de stocks : un logiciel permettant de voir les catalogues des founisseurs de ton entreprise, avec les tarifs négociés, en autorisant les utilisateurs de passer commande de ces fournitures lorsque le besoin se fait sentir. L'intérêt pour ta direction est de centraliser et contrôler les commandes d'achat, et d'éviter les commandes passées "sauvagement" à des fournisseurs inconnus ou non négociés. Le fonctionnement est un peu celui d'un catalogue de vente en ligne mais " à l'envers", en produisant des bons de commande achat et non des factures de vente. Tu pourrais t'adresser à un prestataire de service e-commerce qui saura adapter un logiciel de vente en ligne à ta problématique.

Moi j'essayerais (d'après mes modestes connaissances en mysql)...: ALTER TABLE ibf_members ADD points INT(11) DEFAULT '100' NOT NULL; ALTER TABLE ibf_forums ADD PostPoints INT(10) DEFAULT '20' NOT NULL; ALTER TABLE ibf_forums ADD ReplyPoints INT(10) DEFAULT '10' NOT NULL;

Tu peux pas faire plus optimisé ! L'algo SQL ci-dessus est utilisé par les grands éditeurs d'ERP depuis très longtemps pour les nomenclatures de production. En revanche si tu fais du SQL "classique" tu auras bcp de problème dans la réalisation de ce module : par exemple répercuter les changements faits dans un noeud enfant sur tous ses parents. Si tu le développes en procédures stockées c'est encore mieux pour les performances. Un treeview en ajax te permet de ne charger que les noeuds immédiatement inférieurs à chaque clic et non pas l'ensemble de l'arbre enfant : donc tu n'auras pas plus d'une fraction de seconde à attendre après chaque clic pour voir se développer ton arborescence.

Bonjour et bienvenue sur le Hub. Tu peux faire : UPDATE products SET products_price='0' (mise à 0) UPDATE products SET products_price=NULL (vide le champ)

J'ai développé une gestion de nomenclatures de produit avec un algorithme similaire. Justement sa force est de pouvoir réutiliser un sous arbre pour plusieurs parents sans avoir d'enregistrement redondant dans la base. Pour l'interface, je te conseille vivement un treeview en ajax ce qui permet de charger seulement les noeud enfants au fur et à mesure de la recherche, d'où une simplification de l'algorithme de présentation et un gain de performance très important sur une grosse table.

D'accord avec les avis précédents, fais un script photoshop, si ce n'est pas possible il faudrait pouvoir zoomer sur une grande photo de chaque montre mais cette fois avec la photo dans le bon sens.