J'ai une très grosse table dans laquelle je fais des requetes sur un
champs indéxé.
J'envisage je partitionner cette table.
J'ai quelques questions tout de même avant de procéder à l'opération.
Tout d'abors est ce vraiment utile en terme de performance.
Mon interrogation n'est pas tellement sur les lectures, mais plutôt sur
les lectures et écritures concurrentes.
je passe mon temps a ajouter, modifier, supprimer et lire des
enregistrement dans cette table.
Les transactions lock les tables. Donc je suppose que plus de tables =
moins de conflit non ?
Bref. Est ce que quelqu'un aurai un retour sur l'interet du
partitionnement. Car c'est quand même assez penible à mettre en place
alors autant ne pas le faire pour rien.
Ma deuxième question est:
puisque le partitionnement dans postgreSQL est juste un usage
particulier de l'héritage.
Comment puis-je interdire l'accès en écriture de la table père. Vu que
je vais devoir modifier une application qui pour le moment utilise la
table pére, j'aimerai mettre une contrainte qui m'interdit d'écrire
dedans afin d'être sur de ne pas avoir oublié une requète quelquepart.
Troisième Question:
Existe t-il une instruction qui permette de créer une table sur le
modèle d'une autre.J'aimerai, si c'est possible, éviter de devoir créer
les tables à partir d'un CREATE TABLE.
J'aimerai avoir une partition modèle qui me servierai de base pour la
creation d'une autre partition.
C'est possible ca ?
Enfin.
Lorsqu'on a 100 partitions (qui sont donc 100 tables filles d'une autre
tables), comment fait t-on pour modifier d'un seul coup les 100
partitions. Par exemple, si je dois ajouter un trigger ou une contrainte
sur toutes les partitions ?
Finalement j'ai fait un article sur le sujet du partitionnement comparant les solutions PG et SQL Server : http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner-une-table-comparaison-postg/
En effet, ça refroidi !!! De toute façon ce concept de partition devrait être transparent. il le sera un jour. ca devrait être à la base de données d'organiser ses données au mieux en fonction de l'activité de la base !
En sus tu trouvera de la matière sur l'intérêt du partitionnement dans cet article : http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/
Enfin, découper ta table de manière verticale est une bonne chose.
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière En effet on ne peut concevoir que certaines colonnes fassent partie d'une partition et pas d'une autre. Dans ce cas, il y a un problème de conception du modèle relationnel à la base.
Hum... sauf que moi j'avais bien l'intention de partitionner les colonnes qui peuvent éventuellement être modifiées (is_mail_readed, idmailfolder, ...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
Le 11/10/2011 11:07, SQLpro a écrit :
Finalement j'ai fait un article sur le sujet du partitionnement
comparant les solutions PG et SQL Server :
http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner-une-table-comparaison-postg/
En effet, ça refroidi !!!
De toute façon ce concept de partition devrait être transparent.
il le sera un jour. ca devrait être à la base de données d'organiser ses
données au mieux en fonction de l'activité de la base !
En sus tu trouvera de la matière sur l'intérêt du partitionnement dans
cet article :
http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/
Enfin, découper ta table de manière verticale est une bonne chose.
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent
éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière
En effet on ne peut concevoir que certaines colonnes fassent partie
d'une partition et pas d'une autre. Dans ce cas, il y a un problème de
conception du modèle relationnel à la base.
Hum...
sauf que moi j'avais bien l'intention de partitionner les colonnes qui
peuvent éventuellement être modifiées (is_mail_readed, idmailfolder,
...) sans pour autant partitionner les champs statiques...
Finalement j'ai fait un article sur le sujet du partitionnement comparant les solutions PG et SQL Server : http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner-une-table-comparaison-postg/
En effet, ça refroidi !!! De toute façon ce concept de partition devrait être transparent. il le sera un jour. ca devrait être à la base de données d'organiser ses données au mieux en fonction de l'activité de la base !
En sus tu trouvera de la matière sur l'intérêt du partitionnement dans cet article : http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/
Enfin, découper ta table de manière verticale est une bonne chose.
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière En effet on ne peut concevoir que certaines colonnes fassent partie d'une partition et pas d'une autre. Dans ce cas, il y a un problème de conception du modèle relationnel à la base.
Hum... sauf que moi j'avais bien l'intention de partitionner les colonnes qui peuvent éventuellement être modifiées (is_mail_readed, idmailfolder, ...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
SQLpro
Le 11/10/2011 17:12, Etienne a écrit :
Le 11/10/2011 11:07, SQLpro a écrit :
Finalement j'ai fait un article sur le sujet du partitionnement comparant les solutions PG et SQL Server : http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner-une-table-comparaison-postg/
En effet, ça refroidi !!! De toute façon ce concept de partition devrait être transparent. il le sera un jour. ca devrait être à la base de données d'organiser ses données au mieux en fonction de l'activité de la base !
En sus tu trouvera de la matière sur l'intérêt du partitionnement dans cet article : http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/
Enfin, découper ta table de manière verticale est une bonne chose.
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière En effet on ne peut concevoir que certaines colonnes fassent partie d'une partition et pas d'une autre. Dans ce cas, il y a un problème de conception du modèle relationnel à la base.
Hum... sauf que moi j'avais bien l'intention de partitionner les colonnes qui peuvent éventuellement être modifiées (is_mail_readed, idmailfolder, ...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
Si c'est une bonne idée... Surtout si il existe un fort taux de NULL
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Le 11/10/2011 17:12, Etienne a écrit :
Le 11/10/2011 11:07, SQLpro a écrit :
Finalement j'ai fait un article sur le sujet du partitionnement
comparant les solutions PG et SQL Server :
http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner-une-table-comparaison-postg/
En effet, ça refroidi !!!
De toute façon ce concept de partition devrait être transparent.
il le sera un jour. ca devrait être à la base de données d'organiser ses
données au mieux en fonction de l'activité de la base !
En sus tu trouvera de la matière sur l'intérêt du partitionnement dans
cet article :
http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/
Enfin, découper ta table de manière verticale est une bonne chose.
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent
éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière
En effet on ne peut concevoir que certaines colonnes fassent partie
d'une partition et pas d'une autre. Dans ce cas, il y a un problème de
conception du modèle relationnel à la base.
Hum...
sauf que moi j'avais bien l'intention de partitionner les colonnes qui
peuvent éventuellement être modifiées (is_mail_readed, idmailfolder,
...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
Si c'est une bonne idée... Surtout si il existe un fort taux de NULL
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Finalement j'ai fait un article sur le sujet du partitionnement comparant les solutions PG et SQL Server : http://blog.developpez.com/sqlpro/p10378/langage-sql-norme/partitionner-une-table-comparaison-postg/
En effet, ça refroidi !!! De toute façon ce concept de partition devrait être transparent. il le sera un jour. ca devrait être à la base de données d'organiser ses données au mieux en fonction de l'activité de la base !
En sus tu trouvera de la matière sur l'intérêt du partitionnement dans cet article : http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/
Enfin, découper ta table de manière verticale est une bonne chose.
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière En effet on ne peut concevoir que certaines colonnes fassent partie d'une partition et pas d'une autre. Dans ce cas, il y a un problème de conception du modèle relationnel à la base.
Hum... sauf que moi j'avais bien l'intention de partitionner les colonnes qui peuvent éventuellement être modifiées (is_mail_readed, idmailfolder, ...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
Si c'est une bonne idée... Surtout si il existe un fort taux de NULL
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Etienne
Le 12/10/2011 11:10, SQLpro a écrit :
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière En effet on ne peut concevoir que certaines colonnes fassent partie d'une partition et pas d'une autre. Dans ce cas, il y a un problème de conception du modèle relationnel à la base.
Hum... sauf que moi j'avais bien l'intention de partitionner les colonnes qui peuvent éventuellement être modifiées (is_mail_readed, idmailfolder, ...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
Si c'est une bonne idée... Surtout si il existe un fort taux de NULL
A +
Ok. bon ben je m'y colle alors... Merci.
Le 12/10/2011 11:10, SQLpro a écrit :
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent
éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière
En effet on ne peut concevoir que certaines colonnes fassent partie
d'une partition et pas d'une autre. Dans ce cas, il y a un problème de
conception du modèle relationnel à la base.
Hum...
sauf que moi j'avais bien l'intention de partitionner les colonnes qui
peuvent éventuellement être modifiées (is_mail_readed, idmailfolder,
...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
Si c'est une bonne idée... Surtout si il existe un fort taux de NULL
Tu veux dire séparer les champs qui ne change pas des champs qui peuvent éventuellement être modifiés.
J'ai lu dans ton article
2.2 - le partitionnement doit concerner la table tout entière En effet on ne peut concevoir que certaines colonnes fassent partie d'une partition et pas d'une autre. Dans ce cas, il y a un problème de conception du modèle relationnel à la base.
Hum... sauf que moi j'avais bien l'intention de partitionner les colonnes qui peuvent éventuellement être modifiées (is_mail_readed, idmailfolder, ...) sans pour autant partitionner les champs statiques...
C'est donc pas une bonne idée ???
Etienne
Si c'est une bonne idée... Surtout si il existe un fort taux de NULL
