kexi: un Access-like sous KDE

Posté par  . Modéré par Nÿco.
Étiquettes :
0
15
mai
2003
KDE
Bien plus qu'un simple habillage graphique pour MySQL, la nouvelle application associée à KOffice 1.3 beta apporte: une interface simple à une base de données pour la bureautique, l'administration de la base en backend, la conception visuelle des tables et relations, la création de formulaires de saisie pour l'utilisateur, un support de programmation à base de javascript et bien sûr l'intégration à la suite KOffice. Donc la conception de petites applis tout comme Acc..arghhhh !

Note: je ne parle pas le Jean-Claude, je suis juste dans l'informatique ; )

Aller plus loin

  • # Re: kexi: un Access-like sous KDE

    Posté par  . Évalué à 3.

    Impressionant ! C'est marrant ca a l'air très avancé, et pourtant c'est la première fois que j'en entends parler !

    • [^] # Re: kexi: un Access-like sous KDE

      Posté par  (site web personnel) . Évalué à 3.

      A priori, c'est un morceau de koffice.
      Alors les développeurs ont probablement voulu avoir, dès la première version éditée, quelque chose de déjà utilisable, histoire de ne pas donner à koffice une réputation de suite "pas encore finie parce qu'en cours de developpement..."

    • [^] # Re: kexi: un Access-like sous KDE

      Posté par  . Évalué à -1.

      Ca à l'air plus avancé que certaines solutions sous windows ( Mysql-Front & SQLyog ), va falloir que j'emerge ca :)

  • # Re: kexi: un Access-like sous KDE

    Posté par  . Évalué à 3.

    C'est très impressionant.


    Et c'est la preuve que linux est prêt pour le desktop ! Avec ça, les développements sauvages vont enfin pouvoir fleurir dans tous les coins sur les machines.

  • # Re: kexi: un Access-like sous KDE

    Posté par  . Évalué à 3.

    quelqu'un connait d'autres softs libres *valable* du meme genre ?

  • # Re: kexi: un Access-like sous KDE

    Posté par  . Évalué à 3.

    J'ai juste regardé les screenshots, et c'est très joli. Bon, je vais un peu fouiller au niveau des spécifications (voir si on peut choisir Postgres au lieu de MySQL, etc), mais à priori, voilà qui va permettre un certain nombre de développement 'rapide' de base de données.
    A tester, donc...

    • [^] # Re: kexi: un Access-like sous KDE

      Posté par  . Évalué à 10.

      Lu sur la page d'informations du projet :
      Kexi is aimed to be an easy to use frontend to various database backends. At the moment this documentation is written, only MySQL as server based database and CQL++ as integrated single user backends. It is planned to support other database systems too for better corporate usage in the next versions.

      Ceci dit, je me suis posé la même question.

      En fait, ça a l'air pas mal, en effet. Je suis un peu dégouté, car je me suis lancé dans un projet similaire pour postgreSQL, et du coup, j'arrive trop tard.

      Enfin, je vais continuer quand même, car si je n'arrive pas à un produit aussi abouti, au moins j'aurais fouillé un peu (côté programmation KDE & postgreSQL au moins).

      • [^] # Re: kexi: un Access-like sous KDE

        Posté par  . Évalué à 10.

        Pourquoi ne pas participer à ce projet et faire un module pour postgresql ?

        • [^] # Re: kexi: un Access-like sous KDE

          Posté par  . Évalué à 6.

          Ben.... maintenant que je suis devant le fait accompli, je ne sais plus trop quoi penser. Je continue en freelance, car je suis loin d'être un expert en programmation.

          De plus, mon projet, tout en étant similaire, devrait apporter des fonctionnalités en plus qui je pense sont non-négligeable.

          Par exemple, j'aimerai arriver à récupérer des tables systèmes de postgres l'organisation des tables (structure et liens), de façon à ne pas avoir à m'occuper des clauses 'where' d'une requête.
          Exemple :
          Table A, champ n lié à table B champ n.
          Table B, champ m lié à table C champ m.

          Je choisis un champ de A et un champ de C (dans l'interface graphique), et mon prog me complète tout seul "where A.n = B.n and B.m = C.m". Ceci étant fait, mon code SQL est généré correctement, et il ne me reste plus qu'à me concentrer sur les éventuels filtres que je veux appliquer (and A.n = '10', par exemple).

          Bref, pour en revenir à kexi, sur la page d'infos on peut aussi y lire que l'interfaçage avec odbc est prévu pour les prochaines releases. Mais on ne mentionne pas postgreSQL. Je trouve ça dommage de devoir passer par odbc quand postgreSQL sait tout faire (en tout cas pour la partie qui le concerne directement). Peut-être que ça viendra. A suivre !

          • [^] # Re: kexi: un Access-like sous KDE

            Posté par  . Évalué à 1.

            Il est en ligne quelque part ton projet?

            • [^] # Re: kexi: un Access-like sous KDE

              Posté par  . Évalué à 4.

              Que non ! J'en suis à une phase pré-alpha de base qui ne fait rien d'autre que de me lister les base de données gérées par mon serveur postgres pour l'instant. C'est déjà un début, mais ça ne fait pas grand chose. Je travaille dessus en ce moment, d'ailleurs.

              Il n'est commencé que depuis lundi, c'est donc du tout neuf.

              Parmis les fonctionnalités, j'aimerais gagner assez rapidement l'interface complète de pgaccess, pour ceux qui connaissent. Ce produit est pas mal, mais je crois savoir qu'il n'est plus très activement suivi. Et puis, ce qui me déplait royalement dans ce "truc" c'est qu'il me créé des tables pga_* dans mes bases sans me demander l'autorisation, et rien que ça, ça me gave. Voilà pourquoi je me suis lancé.
              Si jamais j'arrive à quelque chose de propre et fonctionnel, je passerais une news ici bas pour vous tenir au courant, ne vous inquiétez pas.

              P.S. : Il n'est pas question que je lache mon projet pour l'instant. Je ne reprends pas les remarques faites ci-dessus, car vous les avez sûrement déjà lues, mais je veux juste ajouter que de toutes façons, même si mon produit n'est pas aussi fonctionnel/complet/cequevousvoulez que kexi, au moins, ce sera mon "oeuvre" et cela m'aura au moins permis de comprendre comment fonctionne tout ce bazard ;-)

              • [^] # Re: kexi: un Access-like sous KDE

                Posté par  . Évalué à 1.

                Ah oui le coup des tabels pga_* sous pgaccess, je connaissais ça aussi, ce que j'aime pas aussi c'est le réfraîchissement des listes dans pgaccess, il remonte systèmatiquement au début à chaque nouvelle entrée :((

          • [^] # Re: kexi: un Access-like sous KDE

            Posté par  . Évalué à 9.

            En SQL, il existe l'opérateur NATURAL JOIN !!!

            Cet opérateur, effectue automatiquement la jointure entre les champs de noms identiques:

            SELECT Client_Nom, Commande_Numero
            FROM client NATURAL JOIN commande
            WHERE Client_Nom LIKE 'dupon?';

            est strinctement identique à

            SELECT Client_Nom, Commande_Numero
            FROM client, commande
            WHERE client.client_numero = commande.client_numero
            AND Client_Nom LIKE 'dupon?';

            La premiere solution est quand meme légerement plus agréable a écrire !!!

            • [^] # Re: kexi: un Access-like sous KDE

              Posté par  . Évalué à 1.

              En SQL, il existe l'opérateur NATURAL JOIN !!!

              Bordel, je ne connaissais pas.... Mais bon, au vu de

              Cet opérateur, effectue automatiquement la jointure entre les champs de noms identiques:

              J'en comprend que si les noms de champs ne sont pas identiques, ça ne fonctionne pas. Or, il s'avère que j'ai beaucoup de cas comme ça. Mais bon, je retiens l'idée. Après tout, vu que je veux un designer graphique pour écrire mes requêtes, il serait peut-être plus judicieux de ma part de laisser cette possibilité.... En tout cas, c'est noté, et ce sera testé bientôt !

            • [^] # Re: kexi: un Access-like sous KDE

              Posté par  . Évalué à 7.

              Non, l'opérateur JOIN n'est pas "strictement identique".

              Pour le résultat, ce sera effectivement pareil, mais l'optimiseur peut traiter différemment le = et le "[INNER] JOIN".

              Par exemple, dans tous les SGBD que je connais, l'optimiseur syntaxique ne considère pas que la relation "=" est transitive. Donc si on fait une requete de type :

              A.id = B.id
              AND B.id = C.id

              l'optimiseur syntaxique n'en déduit pas que

              A.id = C.id

              Du coup, lorsque l'optimiseur statitistique évaluera les plans d'exécutions possibles, il évaluera le plan en utilisant A ou C comme table directrice, mais jamais B. (quand on sait ce qu'on fait, ça peut être pratique pour blouzer l'optimizeur, mais 99 fois sur 100, c'est une mauvaise idée).

              Pourquoi le "=" n'est pas transitif ? Parce que sinon on arrive à des combinatoires trop complexes pour le choix du plan d'exécution. Par exemple si je fais :

              WHERE client.id = commandes.client_id
              AND client.id = 12345

              Il faudrait que l'optimiseur evalue également :

              client.id = commandes.client_id
              AND commandes.client_id = 12345

              et donc qu'il évalue aussi :
              WHERE commandes.client_id = client.id
              AND client.id = 12345

              et
              WHERE commandes.client_id = client.id
              AND commandes.client_id = 12345

              (choix de table directrice)

              Pour peu que la jointure soit faite sur 4 tables, et qu'il y ait 2 ou 3 gags de ce genre, le SGBD va passer plus longtemps à évaluer des plans d'exécution qu'à effectuer des requêtes :o)

              Par contre, un optimiseur syntaxique (voire statistique), PEUT tout à fait traiter différemment le JOIN. Et si l'optimiseur est codé pour le faire, il choisira le plan d'exécution plus intelligemment qu'avec des "=".

              • [^] # Re: kexi: un Access-like sous KDE

                Posté par  . Évalué à 1.

                J'ai oublié la conclusion : le JOIN c'est mieux :-)

              • [^] # Re: kexi: un Access-like sous KDE

                Posté par  . Évalué à 1.

                Je suis 100% d'accord, mais n'ai pas allourdi mon propos avec les considérations de perfs.

                J'en connaissais pas autant sur l'optimisation de requete, Je ne les pas précisé mais d'un point de vue performance, j'avais retenu que
                FROM A, B
                fait un produit cartésien des deux tables soit Card(A)*Card(B) lignes, puis filtre les lignes qui vérifie le WHERE, alors que dans le cas d'une vraie jointure, cela se passe différement (sans entrer dans les détails).

          • [^] # Re: kexi: un Access-like sous KDE

            Posté par  . Évalué à 3.

            Regarde :
            http://members.shaw.ca/dkite/may22003.html#fKoffice(...)

            Dawit Alemayehu a débuté un pilote PostgreSQL pour Kexi. C'est le moment de sauter dans la barque sinon comme programmeur, au moins comme testeur si tu as des compétences sur PostgreSQL.

            Pour refroidir un peu les ardeurs sur Kexi, Lucijan Busch, le développeur principal, a indiqué dernièrement sur la liste de diffusion de KOffice qu'il ne croyait pas que Kexi serait dans un état de stabilité suffisante avant octobre et qu'il ne pensait pas l'inclure dans la prochaine version de KOffice qui doit sortir auparavant.

            Evidemment, tout cela dépend des volontaires qui rejoindront le projet. Si on pouvait avoir le plus tôt possible une base de données conviviale sous Linux, ce serait encore un gros trou de bouché.

      • [^] # Re: kexi: un Access-like sous KDE

        Posté par  (site web personnel) . Évalué à 7.

        Il faut pas abandonner, quand tu as une idée ou que tu commences un projet, tu peux être sûr à 99% que quelqu'un y a déjà pensé ou l'a même déjà entamé. Ce n'est pas pour çà qu'il faut arrêter, parce que sinon personne ne ferait jamais rien. Au contraire, il faut continuer parce que

        - la concurrence et l'émulation ont du bon
        - même si tu n'es pas LE premier à faire un truc, tu es au moins PARMI les premiers, ce qui est un gros avantage.
        - C'est mieux d'avoir le choix entre plusieurs logiciels pour la même fonction.

        • [^] # Re: kexi: un Access-like sous KDE

          Posté par  . Évalué à 1.

          Bah, si tous le monde suivait ce principe il n'y aurait pas un seul noyeau Linux, mais un noyau AlanCoxus, un Thorvardus, un ...

          C'est avec ce genre de raisonnement qu'on se retrouve avec plein de logiciels pas tres puissant et quasi-inutile.. Un access-like est suffisamment complexe pour avoir besoin de plusieurs programmeurs!

          Je pense qu'il serait beaucoup plus raisonnable d'évaluer d'abord kexi qui a l'air quand même relativement avancé, voir si le code plait, proposer quelques patches, discuter avec le(s) développeurs et si le contact se fait bien contribuer réellement a kexi..

          • [^] # Re: kexi: un Access-like sous KDE

            Posté par  . Évalué à 1.

            bah justement si je me trompe pas il y a déjà un noyau d'alan cox etc...

            celui de linus est celui de réference c'est tout

          • [^] # Re: kexi: un Access-like sous KDE

            Posté par  . Évalué à 1.

            Ce que tu dis est très juste, en effet.
            Ceci étant dit, je n'ai jamais dit que j'allais ré-écrire un acces like, je n'ai d'ailleurs pas défini clairement mon projet. Et pour cause : je n'ai les idées claires sur ce point que depuis peu (j'en suis à la phase "designer" si on peut dire). En fait, je veux (à tout le moins pour mon usage perso) réaliser un PGACCESS like, mais intégré à KDE. C'est un choix, c'est mon choix. Un, parce que j'aime bien et KDE et postgreSQL, et deux, car pgaccess est plus ou moins suivi et a des "features" que je n'aime pas trop (genre la création de tables sans demander l'avis de quiconque, par exemple).
            De plus, je n'ai jamais indiqué que mon projet serait distribué. En effet, je ne pense pas (peut-être à tort, mais je me garde ça pour un futur plus ou moins lointain) que ça intéressera beaucoup de monde. Par ailleurs, je ne le fait ni pour concurrencer pgaccess, ni kexi, ni tora ou autres, mais surtout, et c'est ma motivation principale, car j'ai envie d'apprendre à programmer pour KDE, et parce que j'ai envie de me casser à me fabriquer mes propres outils. Ne serait-ce que pour l'intérêt didactique et éducatif.
            Quant-à joindre le projet de kexi, pourquoi pas. Je n'ai jamais encore codé avec d'autres. C'est tout juste si je sais me servir de CVS...
            Bref, pleins de difficultés à applanir avant de décider de m'intégrer à un projet. Car je reste convaincu d'une chose (qui reste une opinion bien personnelle, je vous l'accorde à tous, lecteurs) : le fait que ces logiciels soient gratuits et libres n'empêchent en rien que les développeurs, codeurs, designers, cequevousvoulezeurs, ne se sentent responsables de ce qu'ils distribuent à travers ces logiciels. Pour ma part, il me semble inconcevable de me lancer dans un projet et de lacher prise au bout de quelques semaines. C'est pourquoi je préfère gravir les échelons tranquillement avant de me lancer dans l'aventure. Mais un jour.... Je me sentirais prêt, et je foncerai. Kexi est un projet jeune, visiblement, il n'y a donc pas péril en la demeure.

      • [^] # Re: kexi: un Access-like sous KDE

        Posté par  . Évalué à 2.

        Comme un des commentaires ci-dessus, je t'encourage à continuer ; en effet, je suppose que tu préfèreras employer ton soft plutôt que Kexi.

        Quelqu'un connaît un soft de ce type sous interface gtk/gnome. Sinon, avis aux amateurs...

  • # oui mais non.

    Posté par  . Évalué à 6.

    Au niveau de l'IHM d'accord mais l'un des avantages (?) de MS Access est de n'avoir qu'un fichier pour une database. Là, c'est du mySql.

    cela dit, ca a l'air sympa.

    • [^] # Re: oui mais non.

      Posté par  . Évalué à 3.

      Avantage ???
      J'ai souvent rencontré des cas d'utilisation où cela n'était pas un avantage. OK, il s'agissait de cas limite puisqu'utilisation multi-utilisateur. Mais bon, finalement, ce n'est pas si limite que cela puisque des développements Access sont souvent déployés comme solution multi-utilisateur. Donc, est-ce réellement un avantage d'avoir un seul fichier ? Ch'uis pas convaincu !

      • [^] # Re: oui mais non.

        Posté par  . Évalué à 1.

        C'est pour ca que j'ai mis le (?) après avantages.


        Cela dit, il peut être intéressant de n'avoir qu'un fichier à balader et de n'avoir qu'un seul programme pour travailer avec et non un serveur complet à installer.

        L'utilisation de petites bases personnels avec des formulaires sympa est une utilisation d'Access, il n'y a - à ma connaissance - aucun LL performant qui offre çà.

        • [^] # Re: oui mais non.

          Posté par  (Mastodon) . Évalué à 2.

          utilise Dbase, OK, c'est pas un fichier, c'est un rep, mais ça se tar très bien pour le transport...
          Et je pense que kexi le supportera rapidement.
          <Ma vie>
          Je me suis fait avec dbase et Delphi un sgbd pour des petites bases perso très performant.
          </Ma vie>

        • [^] # Re: oui mais non.

          Posté par  . Évalué à 2.

          Si Kexi gère un jour Sqlite tu auras ça.

          http://www.sqlite.org(...)

          • [^] # Re: oui mais non.

            Posté par  . Évalué à 2.

            > SQLite is typeless. All data is stored as null-terminated strings. The datatype information that follows the column name in CREATE TABLE statements is ignored (mostly).

            Ca perds tout de même beaucoup d'interet pour faire des requetes. :-(

            • [^] # Re: oui mais non.

              Posté par  . Évalué à 1.

              En quoi ça t'empeche de faire des requetes ? L'intéret est de pouvoir stocker de l'information, y accéder et la modifier. Il ne gère pas les types certes, mais pour une mini base locale cela n'est pas trop génant.

              • [^] # Re: oui mais non.

                Posté par  . Évalué à 1.

                ben, pour faire des rapports, il faut pouvoir faire des tri par date, des additions, soustrations, alors amuse toi à faire cà si les types de bases
                float, int, timestamp ne sont pas intégré.

                en plus, les jointures seront plus lente avec des chaines de caractères qu'avec des entiers.

                SELECT nom, sum(fric) FROM facture, client where date between '05/02/2003' and '10/03/2003' where facture.id_facture
                group by client.nom

                • [^] # Re: oui mais non.

                  Posté par  . Évalué à 1.

                  sqlite> select count(*) from customer where date between '2003-05-15' and '2003-05-16';
                  1
                  sqlite>

                  Ca n'a pas l'air de poser de problème... Je suis en train de développer une application autonome avec Sqlite, j'en saurais plus d'ici quelque temps.

                  • [^] # Re: oui mais non.

                    Posté par  . Évalué à 1.

                    les instructions SUM et COUNt ne sont pas identiques.
                    SUM additionne les valeurs du champ en question.
                    COUNT compte le nombre de lignes. (et ca, ca marche avec un champ typé chaîne de carctère)


                    bon courage.

                    • [^] # Re: oui mais non.

                      Posté par  . Évalué à 0.

                      sqlite> select sum(id) from customer;
                      466652
                      sqlite>

                      le résultat est correct.

        • [^] # Re: oui mais non. (sauf, que, peut-être...)

          Posté par  . Évalué à 1.

          Pour avoir un seul fichier à balader, il y a SQLite qui trashe sa soeur (et même la cousine). C'est là: http://www.sqlite.org/(...) et avec ça et ncurses, fini le tri*** de no*** devant Access :)

          Bonne bourre les dJeunz...

    • [^] # Re: oui mais non.

      Posté par  . Évalué à 4.

      Je ne vois pas pourquoi tu dis ça, Access je m'en suis toujours servi sur des bases distantes grâce aux liens ODBC, et je pense que je ne suis pas le seul. Je te signale aussi qu'un simple "tar cvf mabase.tar /usr/lib/mysql/mabase/' te donnera aussi un seul fichier contenant ta base, si c'est absolument ça que tu veux (pour la sauvegarder par exemple).

      • [^] # Re: oui mais non.

        Posté par  (site web personnel) . Évalué à 8.

        Ca ne sauvegarde pas l'application.

        Sous Access, j'ai un copain qui a fait une base de donnée de ses photos. Il me la passe sur une disquette, je double-clique dessus, et j'ai une interface graphique avec formulaires de saisies, mini-moteur de recherche, ... Sous Access, 1 fichier = tables + meta-données + application (VBA).

        En plus, pour avoir plusieurs instances de la même base sur la même machine, le système 1 fichier = 1 base est particulièrement simple.

        Pour des bases de donnée un minimum important, OK, c'est nul, mais pour le neuneu qui veut faire une mini BD, c'est super, et ça n'existe pas en libre à ma connaissance.

      • [^] # Re: oui mais non.

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        D'accord, mais bon, Marie-Louise, elle s'est fait sa petite base avec une zolie interface en vb, et ça intéresse beaucoup Julie. Et bien avec access, tu as l'interface et la base en un seul fichier, et une seule (hum) appli à installer (acheter). Avec acces + liens odbc, il faut en plus, savoir dumper et restorer une base, et avoir le droit de faire sur le serveur de la boite.

      • [^] # Re: oui mais non.

        Posté par  . Évalué à 2.

        >un seul fichier contenant ta base, si c'est absolument ça que tu veux (pour la sauvegarder par exemple).

        Et si je veux la diffuser ? la personne en face devra installé un serveur MySQl, encore faut-elle qu'elle soit admin pour décompresser la base dans le répertoire var.

        Je ne suis pas un fana d'access, mais le tout en un peu avoir des avantages,

        • [^] # Re: oui mais non.

          Posté par  . Évalué à 5.

          Non, il ne devra pas nécessairement installer MySQL, il peut aussi avoir accès à une base de données SQL.
          Sinon, pour utiliser ta db access, il devra avoir Access. Je ne pense pas qu'il soit possible de rendre ta db Access indépendante du programme, et donc, la problématique est la même.
          Perso, j'ai déjà développé de petites bases de données en PHP + MySQL, et quand je voulais passer la base de donnée, j'apportais le truc sur CD et j'installais EasyPHP c'était souvent des utilisateurs windows). Bon, ok, je le faisais à la place du winuser, mais bon, j'aurais dû aussi installer Access ;-))
          Donc, je ne sais toujours pas si le concept d'Access est vraiment bien ; il est clairement bien implanté dans le monde des particuliers et des entreprises, mais bon, le constat que je fais souvent avec Access est qu'il fait un peu usine à gaz pour les trucs simples, et est trop léger pour les trucs un peu sérieux. Et donc, je me pose la question de savoir ce qui existe entre le truc simple et le truc un peu sérieux (dans mon esprit, cela recouvre les bases de données avec pas mal de contraintes d'intégrité, pas mal de relations, des tables associatives, etc).
          Bref, je continuerai à faire chier mes copains avec PHP et postgresql/mysql (j'en ai même converti, et des pas programmeurs en plus ; bon, ok, c'est encore balbutiant, mais cela fait plaisir quand même ;-))

          • [^] # Re: oui mais non.

            Posté par  . Évalué à 1.

            >Sinon, pour utiliser ta db access, il devra avoir Access. Je ne pense >pas qu'il soit possible de rendre ta db Access indépendante du >programme, et donc, la problématique est la même.

            ben si, du temps ou j'utilisais Access, il existait un runtime permettant de faire tourner une appli sans avoir Access installé. Je ne sais pas si ça existe encore, mais c'est vraissemblable...

          • [^] # Re: oui mais non.

            Posté par  . Évalué à 3.

            Je ne pense pas qu'il soit possible de rendre ta db Access indépendante du programme, et donc, la problématique est la même.

            Si c'est possible: niveau donnée, il y'a des redistribuable gratuit, ça vient aussi avec pas mal de produit.

            Niveau GUI, y'a un kit pour publier ses app, une sorte de viewer, mais j'ai l'impression que ça se perd... on développe de moins en moins de truc pro en access j'ai l'impression... (je ne parle pas d'utiliser Jet, le moteur de db d'access, mais de faire l'ihm en access).

            Ceci dit, si tu dois installer EasyPHP chez qq pour montrer ton boulot, c'est vraiment pas idéal... le must amha serait: une compilation en natif de l'app généré, avec les données intégrées au binaire, ou un seul fichier à côté, avec la possibilité de lui dire d'aller chercher la bd ailleurs... on pourrait alors redistribuer les photos de la grand mère, autant qu'un truc plus conséquent avec une bd centralisées.

            Note aussi que Access peut s'utiliser avec n'importe quelle source ODBC: SQL server, Oracle, ... ou encore MySQL.

    • [^] # Re: oui mais non.

      Posté par  (site web personnel) . Évalué à -1.

      En quoi cela est un avantage ?
      Utiliser MySQL, est un avantage en soi-même, donc ca devrai suffire, non ?

      • [^] # Re: oui mais non.

        Posté par  (site web personnel) . Évalué à -1.

        bof, c'est quand meme mysql hein!

      • [^] # Re: oui mais non.

        Posté par  . Évalué à -4.

        Le principe d'une base de données est entre autres de regrouper toutes les données sur un seul fichier.

        • [^] # Re: oui mais non.

          Posté par  (site web personnel) . Évalué à 1.

          Ah, c'est nouveau ?
          Je croyais que c'était pour faire des requêtes...
          Remarque, une tarball, c'est pratique : DELETE * FROM plop.tar.gz ça se traduit par rm plop.tar.gz

    • [^] # Re: oui mais non.

      Posté par  . Évalué à 5.

      Si j'ai bien compris, l'utilisation de CQL++ permet de n'avoir qu'un fichier, comme sous access.... (maintenant, je peu avoir compris de travers, mais il me semble que c'est ça....)
      Ca en fait donc un produit très intéréssant.

    • [^] # Re: oui mais non.

      Posté par  (site web personnel) . Évalué à 1.

      Il faudrait qu'il définisse un format XML d'échange de donné et le tour est joué comme pour OOo.

      "La première sécurité est la liberté"

  • # Appel a correcteur

    Posté par  (site web personnel) . Évalué à -4.

    une interface simple à une base de données

    juste en passant

    ~set(~score(-1))

  • # Re: kexi: un Access-like sous KDE

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    question un peu HS : est-ce que les formats koffice sont compatibles avec OpenOffice ?

    Pasque si j'installe Linux à ma mère, je lui mets koffice ou openoffice ?

    Mes livres CC By-SA : https://ploum.net/livres.html

  • # et pendant ce temps là...

    Posté par  . Évalué à 1.

    Ou en est mergeant??

    Ca avair l'air plus ouvert au niveau des db (via plugins) mais moins "access-like".
    C'en est où?

    je l'attend avec impatience....

  • # format embarqué

    Posté par  . Évalué à 3.

    "kexi aims to be a database tool for average users but also for professional users. it is based on kde for the ui and on it's own database-library KexiDB which is ANSI-compatible."


    http://luci.bux.at/projects/kexi/(...)

  • # Pourquoi pas PHP ?

    Posté par  . Évalué à 1.

    Le language utilisé (*) sera le javascript...

    J'aurai mieux aimé PHP : plus de possibilité, plus souple, plus d'extention...

    (*) pour le "support de programation".

  • # Migration

    Posté par  . Évalué à 5.

    Et pour migrer d'Access vers Mysql, Postgresql ou autre :

    http://mdbtools.sourceforge.net(...)

    shot :
    http://mdbtools.sourceforge.net/gmdb/gmdb2screenshot.png(...)

  • # et puis il y a noSQL

    Posté par  . Évalué à 1.

    http://www.linux.it/~carlos/nosql/index.html(...)

    Une base de donnees sans mysteres, qui fait appel aux commandes (b)ash, valable pour le desktop

  • # Re: kexi: un Access-like sous KDE

    Posté par  (site web personnel) . Évalué à 1.

    ouais, ben finalement, faudra attendre la version 1.4 de koffice pour voir kexi intégré... pas encore assez éprouvée :
    http://kt.zork.net/kde/kde20030517_51.html#5(...)

  • # Re: kexi: un Access-like sous KDE

    Posté par  . Évalué à 1.

    un peut dommage que gnome n'est pas la même energie pour ses outils...
    gnome-db est un peut vieillot...

  • # Re: kexi: un Access-like sous KDE

    Posté par  . Évalué à 1.

    Introduction

    Les performances et la précision des recherches Google reposent sur la qualité du matériel et des logiciels utilisés. La quasi-instantanéité des résultats est due en partie à l'efficacité de notre algorithme de recherche et en partie aux milliers (!) de PC que nous avons installés en réseau pour constituer un moteur de recherche ultrarapide.

    L'élément fondamental de notre logiciel est PageRank, un système de classement des pages Web mis au point par les fondateurs de Google (Larry Page et Sergey Brin) à l'université de Stanford. Et pendant que plusieurs dizaines d'ingénieurs et de spécialistes consacrent leurs journées à améliorer les différents aspects de Google, PageRank reste la pierre angulaire de nos outils de recherche.

    PageRank
    PageRank est un champion de la démocratie : il profite des innombrables liens du Web pour évaluer le contenu des pages Web -- et leur pertinence vis-à-vis des requêtes exprimées. Le principe de PageRank est simple : tout lien pointant de la page A à la page B est considéré comme un vote de la page A en faveur de la page B. Toutefois, Google ne limite pas son évaluation au nombre de « votes » (liens) reçus par la page ; il procède également à une analyse de la page qui contient le lien. Les liens présents dans des pages jugées importantes par Google ont plus de « poids », et contribuent ainsi à « élire » d'autres pages.

    Les sites qui se distinguent par leur qualité sont affectés d'une valeur PageRank plus élevée, et Google en tient compte lors de chaque recherche. Bien entendu, les pages jugées « importantes » par Google vont vous laisser indifférent si elles ne répondent pas à vos requêtes... Aussi, pour retrouver les pages qui correspondent au mieux à votre requête, Google complète l'évaluation PageRank par des mécanismes évolués de correspondance de texte. Google ne se contente pas de compter le nombre d'occurrences d'un terme de recherche dans une page : il examine différents aspects du contenu de cette page (et du contenu des pages liées à celle-ci) afin de déterminer si elle correspond à votre requête.

    Intégrité
    Les méthodes complexes et automatiques utilisées par les recherches Google rendent quasi impossible toute manipulation humaine des résultats. Comme nous l'indiquons clairement dans nos listes de résultat, certains sites peuvent être associés à une publicité « Sponsored Link »). Toutefois, Google ne pratique pas la vente des positions dans ces résultats ; autrement dit, il n'est pas possible d'acheter une valeur PageRank supérieure à la réalité du Web. Avec la recherche Google, vous disposez d'une solution simple, rapide, honnête et objective pour trouver des sites Web de la plus haute qualité et dont les informations répondent parfaitement à vos besoins.

    Pourquoi Google ?

    La raison prépondérante est claire comme de l'eau de Google : les résultats de recherche les plus pertinents et les plus rapides ! L'extraordinaire volume d'informations disponible sur le Web n'est séduisant que si vous disposez d'un service de recherche vous permettant d'accéder rapidement et efficacement à l'information utile à vos besoins. En l'absence d'un outil de recherche puissant et efficace, il peut être très difficile -- voire impossible -- de retrouver l'information requise. Voici quelques raisons qui justifient le choix de Google :

    Google, la fin du chaos !
    Google maîtrise l'information en proposant un nouveau type de recherche : non pas un répertoire/annuaire à portée limitée ni une liste de résultats adjugés à la plus forte enchère, mais une solution ingénieuse et efficace qui organise le Web en tenant compte de sa structure vaste et démocratique.

    Google, près de deux milliards d'adresses URL !
    L'index de Google, qui porte sur près de deux milliards d'adresses URL, est le premier du genre et il constitue la collection la plus complète de pages Web à contenu utile.

    Google, champion de la pertinence !
    Contrairement à la plupart des autres moteurs de recherche, Google limite ses résultats aux pages Web qui contiennent tous vos termes de recherche (dans le texte de la page ou dans les liens qui pointent sur celle-ci). Fini la frustration des pages sans aucun rapport avec votre requête !

    Google, la proximité !
    Avant de proposer une page, Google vérifie qu'elle contient tous vos termes de recherche, mais il analyse également la proximité de ces termes. Contrairement à la plupart des autres moteurs de recherche, Google privilégie les résultats en fonction de la proximité des termes de recherche ; les résultats proposés en premier sont ceux dans lesquels vos termes de recherche sont aussi proches que possible, ce qui limite (ou élimine !) les pages non pertinentes.

    Google, le contexte en direct !
    Au lieu de proposer un résumé de page statique, Google affiche pour chaque résultat un extrait du texte de la page qui contient vos termes de recherche, ce qui vous permet de déterminer instantanément si le reste de cette page est susceptible de répondre à votre besoin d'information.

    Google, la chance au quotidien !
    Parmi ses nombreuses qualités, Google a le don de proposer en première position le résultat qui correspond à 110 % à votre requête ! En fait, nous sommes tellement sûrs de la qualité de notre service de recherche que nous vous proposons le bouton « J'ai de la chance », qui affiche directement (et uniquement) la page Web correspondant au premier résultat de recherche de Google. Avec la fonction « J'ai de la chance », vos recherches sont encore plus rapides -- mais toujours aussi efficaces !

    Google, à votre service 24x7 !
    Google stocke la plupart des pages Web de son index dans une mémoire cache, ce qui vous permet de consulter leur contenu même si leur serveur subit un incident. Par ailleurs, il est souvent plus rapide d'afficher cette page que de suivre son lien (notez toutefois que les informations d'une page cachée peuvent dans certains cas être moins à jour que la page Web proprement dite).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.