SQL create table d'utiliser %type à colonne

Je suis en train de créer un backuptable de l'un de mes tableaux (une fonction),

CREATE TABLE TBTestBackup
           (
             colum1           user.TBTest.colum1%type,
             colum2           user.TBTest.colum2%type,
             colum3           user.TBTest.colum3%type
             colum31           user.TBTest.colum3%type, --new column with same type as colum3
             colum4           user.TBTest2.column15type, --column from other table
             colum4           CHAR    (12 BYTE), --new column with fixed type
           ) TABLESPACE user_DATA

Mais j'rouge cela ne fonctionne pas,
maintenant, ma question est comment pourrais-je faire cela autant dynamique que possible, donc je n'ai pas à mettre à jour les types de données au script de sauvegarde chaque fois que je change un type de données par exemple à partir de:

VARCHAR2(24 CHAR) à VARCHAR2(50 CHAR)

(la table-les colonnes sont fixes, ils ne changeront pas)
cela n'arrive pas souvent, mais nous avons dû faire de temps en temps parce que le terrain n'était pas assez grande pour une valeur spécifique et alors personne n'a mis à jour la sauvegarde-de la table et l'id a donné quelques erreurs.

EDIT: j'ai oublié quelque chose d'indispensable:

  • J'ai ajouter 2 colonnes qui ne sont pas dans la table d'origine, mais doit avoir le même type de données que l'un de la déjà des tables existantes.
    pourrais-je l'utiliser, sélectionnez comme si il aura le même type, mais un autre nom?
    si oui comment dois-je faire?
  • et certains champs d'une autre table (donc je dois utiliser des jointures)

SOMME:

  • Plusieurs colonnes de type provenant de plusieurs tables
  • La nouvelle Colonne avec le Type fixe
  • La nouvelle Colonne avec le type de variable comme colum XY à partir de la table ABC

OriginalL'auteur Vloxxity | 2013-02-01

  1. 2

    Basé sur vos exigences de mises à jour, pour créer une table sur la base des types dans ces deux tableaux:

    create table t1 (col1 number, col2 varchar2(2), col3 date);
create table t2 (col1 varchar2(10 char));

    Vous pouvez simplement se joindre à eux, avec un filtre qui renvoie toujours false comme Orangecrush suggéré:

    create table tb tablespace users as
select t1.col1 as col1, t1.col2 as col2, t1.col3 as col3,
    t1.col3 as col4, t2.col1 as col5, cast(null as varchar2(12 byte)) as col6
from t1
cross join t2
where null is not null;

    Normalement un cross join serait malvenue, mais l'optimiseur est assez intelligent pour réaliser que le filtre à dire qu'il n'a pas besoin de toucher les tables. Vous pouvez utiliser une normale inner join si il y a des champs, vous pouvez vous joindre sur, bien évidemment.

    desc tb

Name Null Type              
---- ---- ----------------- 
COL1      NUMBER            
COL2      VARCHAR2(2)       
COL3      DATE              
COL4      DATE               -- new column with same type as t1.col3
COL5      VARCHAR2(10 CHAR)  -- column from other table
COL6      VARCHAR2(12)       -- new column with fixed type
    parfait! C'est juste ce dont j'avais besoin! 😀

    OriginalL'auteur Alex Poole

  2. 3

    Vous pouvez utiliser l'instruction pour créer la sauvegarde.

    CREATE TABLE TBTestBackup AS SELECT * FROM ORIGINAL_TABLE_NAME WHERE 1=2;

    C'est en supposant que vous ne souhaitez pas que les données dans la table de sauvegarde. Si vous ne voulez que les données, il suffit de retirer le WHERE condition de la déclaration ci-dessus.

    OriginalL'auteur Orangecrush

  3. 3

    Vous pouvez créer la table avec:

    CREATE TABLE TBTestBackup AS 
SELECT colum1, column2, column2
FROM user.TBTest

    Basé sur votre edit: Vous pouvez modifier l'instruction select pour tout ce que vous voulez. Jointure entre les deux tables et sélectionnez 3 colonnes d'une table et 2 de l'autre

    OriginalL'auteur mavroprovato

  4. 2

    La syntaxe est

    CREATE TABLE TBTestBackup as (SELECT * FROM TBTest)

    Pas sûr de savoir comment vous pouvez automatiser les changements pour les types de données, mais de toute façon ce n'est pas quelque chose qui devrait changer souvent (si il ne vous avez besoin pour travailler).

    OriginalL'auteur Lupuss

  5. 2

    Sonne comme un vue matérialisée serait travailler pour ce que vous voulez.

    create materialized view my_backup
tablespace whatever
nologging
build immediate
refresh complete on demand
as
select t.* 
from some_table t;

    Lorsque vous souhaitez actualiser votre sauvegarde, de faire une actualisation complète sur le tapis de vue:

    exec dbms_mview.refresh('MY_BACKUP', 'C', atomic_refresh=>false);

    Notez également que ce n'est pas un substitut pour RMAN ou d'autres outils utilisés par les Administrateurs de base de données pour faire des sauvegardes, mais correspond à ce que vous demandez à faire.

    Notez également que vous pouvez facilement ajouter des colonnes supplémentaires à la requête en tant que de besoin.

    L'actualisation de la vue matérialisée ne capte pas les modifications de type de données dans la colonne sous-jacente, sera? Vous auriez du faire une erreur lors de l'actualisation si les données ont été trop grand. (Juste essayé cela, la création d'une vue basée sur les tables dans ma réponse, puis, changeant t1.col2 à varchar2(5) et l'insertion d'un 5-char de la valeur. Avant de les insérer la vue refrshes OK, mais encore montre que varchar2(2); après l'insertion rafraîchissante obtient ORA-12899). Le point de vue peut encore être supprimé et recréé, bien sûr, donc dans la plupart des cas, il est toujours mieux que de DEC.

    OriginalL'auteur tbone