RESEUX/INTERNET /LOGICIEL/RECHERCHE/

cs_exar Messages postés 286 Date d'inscription vendredi 5 décembre 2003 Statut Membre Dernière intervention 22 avril 2012 - 12 avril 2009 à 20:31
cs_vicenzo Messages postés 178 Date d'inscription mardi 16 août 2005 Statut Membre Dernière intervention 25 août 2010 - 14 avril 2009 à 11:02
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/49804-reseux-internet-logiciel-recherche

cs_vicenzo Messages postés 178 Date d'inscription mardi 16 août 2005 Statut Membre Dernière intervention 25 août 2010 1
14 avril 2009 à 11:02
@exar

ben justement, pour un petit projet, avoir à compiler une version pour chaque client oracle, c'est une plaie...

:)
cs_exar Messages postés 286 Date d'inscription vendredi 5 décembre 2003 Statut Membre Dernière intervention 22 avril 2012 1
14 avril 2009 à 10:57
@vincenzo
Je suis tout-à-fait d'accord avec toi, mais j'ai pensé à Pro*C parce que le "projet" est assez petit.
Mais tu as vraiment raison en ce qui concerne OCILIB.
Bien à toi !
cs_vicenzo Messages postés 178 Date d'inscription mardi 16 août 2005 Statut Membre Dernière intervention 25 août 2010 1
14 avril 2009 à 10:26
@exar :

Avec PRO*C :
- tu dois compiler un binaire pour chaque version d'oracle
- tu dois avoir un client Oracle pour compiler
- créer un librairie en pro*c (statique / shared) et qui plus est en multithread, c'est galère
- faible support pour C99
- peu adapté au multi-tiers
- tu as déja vu la tête d'un fichier *.c généré par PRO*C ? c'est une plaie à débugger !
- faible support Unicode
- Parfois tu est quasiment obligé à utiliser des types oracle avec les declare section au lieu de type C
- gestion des curseurs archaïque
- etc ....

J'utilise PRO*C sur certains projets au quotidien pour le taf... C'est pas toujours la joie.

Bref, je trouve OCILIB beaucoup souple, plus riche, plus simple notamment pour manipuler certains types comme les lobs, files, objets, intervales ... et pour certaines opérations (piecewise, arrays)

OCILIB est aussi plus "universel" : ISO C (90/99), indépendant de la plateforme, peut être utilisé par tout langage supportant un linkage C, full unicode, compilation possible sans client Oracle, ...

Au final un code ocilib est plus compact (moins de ligne de code q'un *.pc), mille fois plus simple à debugger, ....

En fait OCILIB est un wrapper autour d'OCI.
OCI est l'API "royale", la plus performante, la plus souple. c'est beaucoup mieux que PRO*C. Mais la contrepartie c'est que c'est super complexe (lignes de codes a n'en plus finir, fonction à 15 arguments, ..)
OCILIB est la pour avoir tous les avantage d'OCI avec une interface simple et surtout réutilisable, ce qui est le gros défaut d'OCI et PRO*C
__________________
cs_exar Messages postés 286 Date d'inscription vendredi 5 décembre 2003 Statut Membre Dernière intervention 22 avril 2012 1
12 avril 2009 à 20:31
Bonsoir !

Quelques petites remarques...
1. Pour ta table possede, pourquoi mets-tu une clé primaire technique ? Tu ne mets pas ensuite de clé unique sur idClient et idFichier... Or ces deux champs devraient être uniques ensemble et ainsi constituer ta clé primaire.
2. Pour ta table journal, pourquoi stocker l'adresse IP ? J'aurais mis une référence au client, plutôt (avec foreign key). Même chose pour le fichier (pq stocker son nom et pas l'id ?).
3. Pour tes séquences, pourquoi mettre la maxvalue à 999999 alors que tes clés primaires sont des number(8) ?
4. Dans tes procédures, plusieurs choses: crois-tu que que quelqu'un qui utiliserait ton code va s'amuser à aller voir dans la console les messages dbms_output ? Utilise des exceptions ! En en parlant, aucune exception n'est gérée !
5. Dans tes triggers, tu peux faire le select de la concaténation directement: select 'c'||ma_sequence_Client.nextval into :new.idClient from dual; Si tu utilises Oracle 11g, tu peux même faire: :new.idClient := 'c'||ma_sequence_Client.nextval; Pense également qu'il pourrait y avoir une exception levée.
6. Pour tes tables, vois combien de records, de quelle taille elles vont être remplies. Ensuite, en fonction de cela, crée différents tablespaces adaptés. Il est également mieux d'avoir des tablespaces data et d'autres pour les indexes.
Si tu as besoin de conseils, n'hésites pas !
Pour le code C, je n'ai pas tout regardé, mais ça me semble pas trop mal. Une petite question tout de même: pourquoi ne pas utiliser Pro*C ?
Point super positif: les commentaires doxygen !
Dans tous les cas, bonne continuation et joyeuses Pâques !
Rejoignez-nous