Je ne sui pas sûr de saisir ton argumentaire sur les data-set...
Je connais les Data files et les tablespaces (regroupement logique de datafiles). Oracle permet de fixer une taille minimum a un data file et éventuellement de permettre les auto extends sur le fichier (plutôt dangeureux, a mon avis).
On peut aussi mettre offline certains datafiles, tablespaces... Tout devient très configurable.
Si une table ou in index est mal taillé, il y aura des extends dans le tablespace. Là effectivement c'est pénalisant. Mais ça c'est pas la faute d'Oracle si une table été mal évalué. Un bon DBA suffit pour éviter ce genre de soucis. Une BDD ça vit, donc faut s'en occuper.
Qu'Oracle prenne la main sur le FS est a mon sens nécessaire. L'organisation interne des data files est ainsi optimisées. Et surtout ca permet a Oracle de garde un secret de fonctionnement. Et aussi, peu importe l'OS (et donc le FS) sur lequel il est posé, Oracle n'a juste qu'a modifier les comande de création des datafiles, pour le reste rien ne change. Oracle n'est pas étroitement lié a l'Os qui l'héberge. Tu veux exporte un tablespace d'un Oracle Unix vers un Oracle NT (ou mieux l'inverse) : c'est possible avec un coup d'import/export...
Aujourd'hui Oracle gère les locks au niveau Rows. Bientôt ce sera au niveau Columns. MySQL avec InnoDB est au niveau SQLServer (locks au niveau de page de données il me semble).
Oracle est un SGBD industriel. Il permet de gérer des requête repartié sur plusieurs serveurs distant. Il est ainsi possilbe en une suele requête de faire une jointure entre tables d'instances différentes sans se souciées de la localisation des instances. C'est assez limite comme fonctionnalité, mais dans ma boite c'est très utile.
Il est possible (a partir de la 8i) d'avoir des objet partitionnés : Une table partionnée est une table dont les données sont "rangé" dans des tablepaces définis par le DBA en fonction d'une clé de partition. Quand on a des tables qui prennent de plusieurs de millions de ligne par mois, c'est très utiles. Pour virer les données plus vieilles, un bon truncate sur la partition suffit, alors qu'avant fallait se palucher un delete de la mort avec le risque d'exploser le Rollback segment...
Qu'il faille acheter plein d'outils supplémentaires, c'est normal, c'est pas du freesoftware non plus. Donc faut attendre d'Oracle qu'il fournisse des outils permettant d'exporter des données vers un autre SGDB gratuitement. Je comprend cette position.
Et si Oracle intègre tout un tas de fonctionnalités, c'est pas seulement pour faire joli. C'est parce que des gros comptes font des demandes... Le fonctionnalité sont très nombreuses, mais on les utilise rarement toutes. C'est au DBA de bien taillé et gérer ses bases. Après si on veut se passer de DBA, c'est pas Oracle qu'il faut choisir.
Oracle est complexe ? C'est le défaut des ses avantages, je dirais.
Aujourd'hui quel autre SGBD pourrait héberger une base infocentre, Datamart/Datawarehouse avec plusieurs milliers d'utilisateurs sans broncher ?
Le seul reproche que je ferai a Oracle c'est qu'il permet de pondre requêtes vraiment trop éloigné du standard SQL. Et du coup, les applicatifs deviennent dépendant d'Oracle.
[^] # Re: "Oracle goes linux"
Posté par Padishah . En réponse à la dépêche Long article sur Linux dans Oracle Magazine. Évalué à 2.
Je connais les Data files et les tablespaces (regroupement logique de datafiles). Oracle permet de fixer une taille minimum a un data file et éventuellement de permettre les auto extends sur le fichier (plutôt dangeureux, a mon avis).
On peut aussi mettre offline certains datafiles, tablespaces... Tout devient très configurable.
Si une table ou in index est mal taillé, il y aura des extends dans le tablespace. Là effectivement c'est pénalisant. Mais ça c'est pas la faute d'Oracle si une table été mal évalué. Un bon DBA suffit pour éviter ce genre de soucis. Une BDD ça vit, donc faut s'en occuper.
Qu'Oracle prenne la main sur le FS est a mon sens nécessaire. L'organisation interne des data files est ainsi optimisées. Et surtout ca permet a Oracle de garde un secret de fonctionnement. Et aussi, peu importe l'OS (et donc le FS) sur lequel il est posé, Oracle n'a juste qu'a modifier les comande de création des datafiles, pour le reste rien ne change. Oracle n'est pas étroitement lié a l'Os qui l'héberge. Tu veux exporte un tablespace d'un Oracle Unix vers un Oracle NT (ou mieux l'inverse) : c'est possible avec un coup d'import/export...
Aujourd'hui Oracle gère les locks au niveau Rows. Bientôt ce sera au niveau Columns. MySQL avec InnoDB est au niveau SQLServer (locks au niveau de page de données il me semble).
Oracle est un SGBD industriel. Il permet de gérer des requête repartié sur plusieurs serveurs distant. Il est ainsi possilbe en une suele requête de faire une jointure entre tables d'instances différentes sans se souciées de la localisation des instances. C'est assez limite comme fonctionnalité, mais dans ma boite c'est très utile.
Il est possible (a partir de la 8i) d'avoir des objet partitionnés : Une table partionnée est une table dont les données sont "rangé" dans des tablepaces définis par le DBA en fonction d'une clé de partition. Quand on a des tables qui prennent de plusieurs de millions de ligne par mois, c'est très utiles. Pour virer les données plus vieilles, un bon truncate sur la partition suffit, alors qu'avant fallait se palucher un delete de la mort avec le risque d'exploser le Rollback segment...
Qu'il faille acheter plein d'outils supplémentaires, c'est normal, c'est pas du freesoftware non plus. Donc faut attendre d'Oracle qu'il fournisse des outils permettant d'exporter des données vers un autre SGDB gratuitement. Je comprend cette position.
Et si Oracle intègre tout un tas de fonctionnalités, c'est pas seulement pour faire joli. C'est parce que des gros comptes font des demandes... Le fonctionnalité sont très nombreuses, mais on les utilise rarement toutes. C'est au DBA de bien taillé et gérer ses bases. Après si on veut se passer de DBA, c'est pas Oracle qu'il faut choisir.
Oracle est complexe ? C'est le défaut des ses avantages, je dirais.
Aujourd'hui quel autre SGBD pourrait héberger une base infocentre, Datamart/Datawarehouse avec plusieurs milliers d'utilisateurs sans broncher ?
Le seul reproche que je ferai a Oracle c'est qu'il permet de pondre requêtes vraiment trop éloigné du standard SQL. Et du coup, les applicatifs deviennent dépendant d'Oracle.