Bonjour,
Encore peu familier de Linux, j'aimerais savoir s'il existe des SGBD
simplifiés (moins lourds que MySQL ou Postgresql).
Ils seraient plus adaptés aux nouvelles petites machines style asus 701,
surtout utilisées comme "super PDA".
A ma connaissance, entre les gros SGBD et les outils spécialisés et
indigents style "carnets d'adresse" ou "gestionnaire de morceaux de
musiques", il n'y a rien.
J'ai tj regretté l'archaïque mais astucieux Sharp ZQ 8600 M.
16 Khz , 512 Ko de mémoire, texte brut, bases monotables hélas, mais c'était
déjà l'application que j'utilisais le plus sur cette machine.
Une application permettant simplement de créer des tables, de placer à la
souris les champs dans une vue et de définir des champs lien vers un champ
non dupliqué d'une autre table, sans passer par SQL, devrait être aussi
répandue qu'un traitement de texte ou un tableur, pour créer des petites bases.
Celà DOIT exister !
"OOo Base" existe , mais comme il n'y a pas d'icône de base de données sur Asus 701 (voir p.ex. test illustré sur blogee.net) je me suis demandé si la suite était complète. Qqn ayant cette machine le sait-il ?
J'ai la machine, je n'ai pas vérifié mais "apt-get install openoffice-base" doit suffire, le cas échéant.
Merci. Si je comprends bien le noyau et l'environnement Linux du eeepc sont
assez standard pour ne pas provoquer de pb particuliers d'installation.
Par contre Michel Talon semble penser que ce sgbd n'est pas fiable. As-tu une expérience à ce sujet (dans d'autres Linux) ?
"OOo Base" existe , mais comme il n'y a pas d'icône de base de données sur
Asus 701 (voir p.ex. test illustré sur blogee.net) je me suis demandé si la
suite était complète.
Qqn ayant cette machine le sait-il ?
J'ai la machine, je n'ai pas vérifié mais "apt-get install
openoffice-base" doit suffire, le cas échéant.
Merci. Si je comprends bien le noyau et l'environnement Linux du eeepc sont
assez standard pour ne pas provoquer de pb particuliers d'installation.
Par contre Michel Talon semble penser que ce sgbd n'est pas fiable.
As-tu une expérience à ce sujet (dans d'autres Linux) ?
"OOo Base" existe , mais comme il n'y a pas d'icône de base de données sur Asus 701 (voir p.ex. test illustré sur blogee.net) je me suis demandé si la suite était complète. Qqn ayant cette machine le sait-il ?
J'ai la machine, je n'ai pas vérifié mais "apt-get install openoffice-base" doit suffire, le cas échéant.
Merci. Si je comprends bien le noyau et l'environnement Linux du eeepc sont
assez standard pour ne pas provoquer de pb particuliers d'installation.
Par contre Michel Talon semble penser que ce sgbd n'est pas fiable. As-tu une expérience à ce sujet (dans d'autres Linux) ?
talon
Chris_B wrote:
2) Pour le fait que Kexi et le format de sqlite acceptent n'importe quoi dans un champs numériques, c'est peut-être une simplification pour leur concepteur, mais pas pour l'utilisateur.
Tu peux très bien avoir à utiliser sqlite dans une situation où les différents champs sont essentiellement des blobs, auquel cas tu es bien content que le système ne vienne pas te casser les pieds.
Je ne vois pas alors à quoi servent les types de champs et les risques d'erreur augmentent.
Tu peux très bien utiliser sqlite à traver un programme qui, lui, fait les verifications de type si tu les juges nécessaires. Sqlite supporte des triggers qui peuvent aussi aider pour faire ce genre de choses. Par exemple si tu utilises sqlite via py-sqlite, python peut faire l'interface et les vérifications que tu veux.
Je ne vois pas bien dans quel cas ce serait un avantage, sinon que le logiciel est un peu plus petit.
Plus rapide, plus efficace, etc, dans le cas où tu as besoin d'une base mais que tu te fous des vérifications. Voici ce que la doc de sqlite dit là dessus:
Most SQL database engines use static typing. A datatype is associated with each column in a table and only values of that particular datatype are allowed to be stored in that column. SQLite relaxes this restriction by using manifest typing. In manifest typing, the datatype is a property of the value itself, not of the column in which the value is stored. SQLite thus allows the user to store any value of any datatype into any column regardless of the declared type of that column. (There are some exceptions to this rule: An INTEGER PRIMARY KEY column may only store integers. And SQLite attempts to coerce values into the declared datatype of the column when it can.)
As far as we can tell, the SQL language specification allows the use of manifest typing. Nevertheless, most other SQL database engines are statically typed and so some people feel that the use of manifest typing is a bug in SQLite. But the authors of SQLite feel very strongly that this is a feature. The use of manifest typing in SQLite is a deliberate design decision which has proven in practice to make SQLite more reliable and easier to use, especially when used in combination with dynamically typed programming languages such as Tcl and Python.
--
Michel TALON
Chris_B <christian.bernard16@orange.fr> wrote:
2) Pour le fait que Kexi et le format de sqlite acceptent n'importe quoi
dans un champs numériques, c'est peut-être une simplification pour leur
concepteur, mais pas pour l'utilisateur.
Tu peux très bien avoir à utiliser sqlite dans une situation où les
différents champs sont essentiellement des blobs, auquel cas tu es bien
content que le système ne vienne pas te casser les pieds.
Je ne vois pas alors à quoi servent
les types de champs et les risques d'erreur augmentent.
Tu peux très bien utiliser sqlite à traver un programme qui, lui, fait
les verifications de type si tu les juges nécessaires. Sqlite supporte
des triggers qui peuvent aussi aider pour faire ce genre de choses.
Par exemple si tu utilises sqlite via py-sqlite, python peut faire
l'interface et les vérifications que tu veux.
Je ne vois pas bien
dans quel cas ce serait un avantage, sinon que le logiciel est un peu plus
petit.
Plus rapide, plus efficace, etc, dans le cas où tu as besoin d'une base
mais que tu te fous des vérifications. Voici ce que la doc de sqlite dit
là dessus:
Most SQL database engines use static typing. A datatype is associated
with each column in a table and only values of that particular datatype
are allowed to be stored in that column. SQLite relaxes this restriction
by using manifest typing. In manifest typing, the datatype is a property
of the value itself, not of the column in which the value is stored.
SQLite thus allows the user to store any value of any datatype into any
column regardless of the declared type of that column. (There are some
exceptions to this rule: An INTEGER PRIMARY KEY column may only store
integers. And SQLite attempts to coerce values into the declared
datatype of the column when it can.)
As far as we can tell, the SQL language specification allows the use of
manifest typing. Nevertheless, most other SQL database engines are
statically typed and so some people feel that the use of manifest typing
is a bug in SQLite. But the authors of SQLite feel very strongly that
this is a feature. The use of manifest typing in SQLite is a deliberate
design decision which has proven in practice to make SQLite more
reliable and easier to use, especially when used in combination with
dynamically typed programming languages such as Tcl and Python.
2) Pour le fait que Kexi et le format de sqlite acceptent n'importe quoi dans un champs numériques, c'est peut-être une simplification pour leur concepteur, mais pas pour l'utilisateur.
Tu peux très bien avoir à utiliser sqlite dans une situation où les différents champs sont essentiellement des blobs, auquel cas tu es bien content que le système ne vienne pas te casser les pieds.
Je ne vois pas alors à quoi servent les types de champs et les risques d'erreur augmentent.
Tu peux très bien utiliser sqlite à traver un programme qui, lui, fait les verifications de type si tu les juges nécessaires. Sqlite supporte des triggers qui peuvent aussi aider pour faire ce genre de choses. Par exemple si tu utilises sqlite via py-sqlite, python peut faire l'interface et les vérifications que tu veux.
Je ne vois pas bien dans quel cas ce serait un avantage, sinon que le logiciel est un peu plus petit.
Plus rapide, plus efficace, etc, dans le cas où tu as besoin d'une base mais que tu te fous des vérifications. Voici ce que la doc de sqlite dit là dessus:
Most SQL database engines use static typing. A datatype is associated with each column in a table and only values of that particular datatype are allowed to be stored in that column. SQLite relaxes this restriction by using manifest typing. In manifest typing, the datatype is a property of the value itself, not of the column in which the value is stored. SQLite thus allows the user to store any value of any datatype into any column regardless of the declared type of that column. (There are some exceptions to this rule: An INTEGER PRIMARY KEY column may only store integers. And SQLite attempts to coerce values into the declared datatype of the column when it can.)
As far as we can tell, the SQL language specification allows the use of manifest typing. Nevertheless, most other SQL database engines are statically typed and so some people feel that the use of manifest typing is a bug in SQLite. But the authors of SQLite feel very strongly that this is a feature. The use of manifest typing in SQLite is a deliberate design decision which has proven in practice to make SQLite more reliable and easier to use, especially when used in combination with dynamically typed programming languages such as Tcl and Python.
--
Michel TALON
Nicolas George
Michel Talon, dans le message <fuied9$se9$, a écrit :
Tu peux très bien avoir à utiliser sqlite dans une situation où les différents champs sont essentiellement des blobs, auquel cas tu es bien content que le système ne vienne pas te casser les pieds.
Eh bien dans ce cas, on déclare les champs de type blob, et le système ne vient pas casser les pieds.
Tu confonds « pouvoir ne pas » et « ne pas pouvoir » : ce qui est intéressant pour le programmeur, c'est pouvoir ne pas être embêté par les types quand ça l'arrange, mais la situation, c'est qu'il ne peut pas avoir de vérification.
Michel Talon, dans le message <fuied9$se9$1@asmodee.lpthe.jussieu.fr>, a
écrit :
Tu peux très bien avoir à utiliser sqlite dans une situation où les
différents champs sont essentiellement des blobs, auquel cas tu es bien
content que le système ne vienne pas te casser les pieds.
Eh bien dans ce cas, on déclare les champs de type blob, et le système ne
vient pas casser les pieds.
Tu confonds « pouvoir ne pas » et « ne pas pouvoir » : ce qui est
intéressant pour le programmeur, c'est pouvoir ne pas être embêté par les
types quand ça l'arrange, mais la situation, c'est qu'il ne peut pas avoir
de vérification.
Michel Talon, dans le message <fuied9$se9$, a écrit :
Tu peux très bien avoir à utiliser sqlite dans une situation où les différents champs sont essentiellement des blobs, auquel cas tu es bien content que le système ne vienne pas te casser les pieds.
Eh bien dans ce cas, on déclare les champs de type blob, et le système ne vient pas casser les pieds.
Tu confonds « pouvoir ne pas » et « ne pas pouvoir » : ce qui est intéressant pour le programmeur, c'est pouvoir ne pas être embêté par les types quand ça l'arrange, mais la situation, c'est qu'il ne peut pas avoir de vérification.
