Conversion de type de données de SQL Server à Oracle

Question

Je déplace actuellement un produit de SQL Server à Oracle. Je suis semi-familier avec SQL Server et je ne sais rien sur Oracle, alors je m'excuse si la simple présence de cette question offense quiconque.

déduisant cette page, http://download.oracle.com/docs/cd/E12151_01/doc.150/e12156/ss_oracle_compared.htm, il semblerait que la conversion de type de données de SQL Server à Oracle doit être:

REAL = FLOAT (24) -> FLOAT (63)

FLOAT (p) -> FLOAT (p)

TIMESTAMP -> NUMERO

NVARCHAR (n) -> VARCHAR (n * 2)

NCHAR (n) -> CHAR (n * 2)

Voici mes questions concernant les:

Pour Float, considérant que FLOAT (p) -> FLOAT (p), ne serait pas ce que cela signifie aussi que FLOAT -> FLOAT (24)?

Pour TIMESTAMP, puisque Oracle a aussi sa propre version, ne serait-il pas mieux que TIMESTAMP -> TIMESTAMP? Enfin, pour NVARCHAR (n) et NCHAR (n), je pensais que le problème serait lié à Unicode. Puis, encore une fois, puisque Oracle fournit sa propre version des deux, cela n'aurait-il pas plus de sens que NVARCHAR (n) -> NVARCHAR (n) et NCHAR (n) -> NCHAR (n)?

Il serait très apprécié si quelqu'un devait élaborer sur les 3 questions précédentes.

Merci d'avance.

Answer 1

Il semble que CHAR et VARCHAR2 d'Oracle (utilisent toujours VARCHAR2 au lieu de VARCHAR) prennent déjà en charge Unicode - le document que vous avez lié conseille de convertir ceux des types de données SQL Server NCHAR et NVARCHAR. Le TIMESTAMP de SQL Server n'est pas réellement un horodatage - c'est une sorte d'identifiant basé sur le temps qui vient d'être utilisé pour indiquer qu'une ligne a changé - il ne peut pas être reconverti en n'importe quel type de DATETIME (au moins d'une manière que je connais). Pour FLOAT, l'utilisation de 126 octets serait énorme - puisque les outils de développement mappent automatiquement FLOAT de SQL Server sur FLOAT d'Oracle (53), pourquoi ne pas utiliser cette quantité?

Answer 2

Ceci est plus FYI qu'une réponse à votre question, mais vous allez potentiellement rencontrer une différence particulièrement douloureuse entre SQL Server et Oracle. Dans SQL Server, vous pouvez définir une colonne de chaîne (quelle que soit sa saveur) pour ne pas autoriser les valeurs NULL, puis insérer des chaînes de longueur nulle (alias "vide") dans cette colonne, car SQL Server ne considère pas une chaîne vide comme Identique à une valeur NULL. Considérons une chaîne vide comme identique à une valeur NULL, donc Oracle ne vous laissera pas insérer des valeurs vides dans une colonne NOT NULL. Cela provoque évidemment des problèmes lors de la copie de données d'une table dans SQL Server dans sa table homologue dans Oracle.Vous choix pour faire face à ce sujet sont:

1. Définissez la colonne de chaîne incriminée dans Oracle pour autoriser les valeurs NULL (donc pas une bonne idée)
2. Lors de la copie des données, remplacez les cordes blanc avec autre chose (Je ne sais pas ce que vous devez utiliser ici)
3. Passer les lignes incriminées et prétendre que vous ne les a jamais

J'aimerais penser que le choix d'Oracle à considérer les chaînes vides être NULL (où ils sont seuls parmi les principaux DBs) était de verrouiller les clients dans leur plate-forme, mais celui-ci fonctionne réellement dans la direction opposée. Vous pouvez déplacer une base de données d'Oracle vers autre chose sans la différence vide = NULL causant des problèmes.

Voir cette question plus tôt: Oracle considers empty strings to be NULL while SQL Server does not - how is this best handled?

Answer 3

suivant n'est pas une réponse directe à votre question; mais il est bon de jeter un oeil sur le blog de sqlteam

sqlteam - Datatypes translation between Oracle and SQL Server part 2: number

Il a des explications détaillées sur la façon de traiter numbers, etc.