Domanda

I fornitori DBMS usano caratteristiche dialettali SQL per differenziare il loro prodotto, allo stesso tempo, la pretesa di supportare gli standard SQL. 'Nuff ha detto su questo.

C'è un esempio di SQL che avete codificato, che non può essere tradotto a SQL:? 2008 SQL standard

Per essere precisi, sto parlando di DML (una dichiarazione query), NON DDL, sintassi stored procedure o qualsiasi cosa che non è una dichiarazione di SQL puro.

Inoltre sto parlando di query che si usa in produzione, non per le cose ad-hoc.

Modifica 13 gennaio

Grazie per tutte le vostre risposte: hanno trasmesso a me l'impressione che un sacco di SQL-specifico DBMS è stato creato per consentire work-around per la progettazione relazionale poveri. Il che mi porta alla conclusione probabilmente non voler per porte applicazioni più esistenti.

È stato utile?

Soluzione

differenze tipiche includono la semantica sottilmente differnt (ad esempio Oracle gestisce i NULL in modo diverso da altri dialetti SQL in alcuni casi), diversi meccanismi di gestione delle eccezioni, diverse tipologie e metodi proprietari per fare le cose come operazioni sulle stringhe, operazioni di data o query gerarchiche. hint per la query tendono anche ad avere la sintassi che varia tra le piattaforme, e diversi ottimizzatori possono confondersi su diversi tipi di costrutti.

Si può usare ANSI SQL per la maggior parte attraverso i sistemi di database e si aspettano di ottenere risultati ragionevoli su un database senza problemi di messa a punto significativi come indici mancanti. Tuttavia, su qualsiasi applicazione non banale non è probabile che sia qualche requisito per il codice che non possono essere facilmente fatto portably.

In genere, questo requisito sarà abbastanza localizzato all'interno di una base di codice di applicazione - una manciata di query in cui questo causa un problema. Reporting è molto più probabile per vomitare questo tipo di problema e di fare le query di segnalazione generici che funzionano attraverso editori è molto improbabile che funzioni bene. Alcune applicazioni sono maggiori probabilità di causare il dolore di altri.

Pertanto, è improbabile che basandosi su costrutti SQL 'portatili' per un'applicazione funzionerà nel caso generale. Una strategia migliore è quella di utilizzare le dichiarazioni generiche dove lavoreranno e uscire a un livello specifico database in cui questo non funziona.

Un meccanismo di query generico potrebbe essere quella di utilizzare ANSI SQL ove possibile; un altro approccio possibile potrebbe essere quella di utilizzare un / R mapper O, che può richiedere i driver per diverse piattaforme di database. Questo tipo di meccanismo dovrebbe essere sufficiente per la maggior parte delle operazioni di database, ma richiede di fare un certo lavoro dalla piattaforma specifc in cui si esaurisce di vapore.

Può essere possibile utilizzare stored procedure come un livello di astrazione per operazioni e codice più complessi un insieme di sprocs specifici della piattaforma per ciascuna piattaforma di destinazione. I sprocs potrebbero essere accessibili attraverso qualcosa di simile ADO.net.

In pratica, differenze sottili in paramter passaggio e la gestione delle eccezioni possono causare problemi con questo approccio. Un approccio migliore è quello di realizzare un modulo che avvolge il operazioni di database specifici per la piattaforma con un'interfaccia comune. diversi moduli 'Driver' possono essere messe e tolte a seconda di quale piattaforma DBMS in uso.

Altri suggerimenti

Oracle ha alcune aggiunte, come ad esempio modello o gerarchica query che sono molto difficile, se non impossibile, tradurre in puro SQL

Anche quando SQL: 2008 può fare qualcosa a volte la sintassi non è la stessa. Prendere la sintassi REGEXP corrispondenza per esempio, SQL:. 2008 utilizza LIKE_REGEX vs REGEXP di MySQL

E sì, sono d'accordo, è molto fastidioso.

La parte del problema con Oracle è che è ancora basato sullo standard ANSI SQL 1992. SQL Server è in SQL 1999 standard, quindi alcune delle cose che sembrano "estensioni" sono in realtà gli standard più recenti. (Credo che la clausola "OVER" è uno di questi.)

Oracle è anche molto più restrittivo su come piazzare sottoquery in SQL. SQL Server è molto più flessibile e permissivo di permettere sottointerrogazioni quasi ovunque.

SQL Server ha un modo razionale per selezionare la riga "top" di un risultato: "SELECT TOP 1 VERSO CLIENTELA ORDER BY SALES_TOTAL". In Oracle, questo diventa "SELECT * FROM (SELECT CLIENTI ORDER BY SALES_TOTAL) WHERE ROW_NUMBER <= 1".

E naturalmente c'è sempre infame SELEZIONA di Oracle (espressione) FROM DUAL.

Modifica per aggiungere:

Ora che sono al lavoro e può accedere ad alcuni dei miei esempi, ecco una buona. Questo è generato da LINQ to SQL, ma è una query pulito per selezionare le righe da 41 a 50 da una tabella, dopo la cernita. Esso utilizza la clausola "OVER": 

SELECT [t1].[CustomerID], [t1].[CompanyName], [t1].[ContactName], [t1].[ContactTitle], [t1].[Address], [t1].[City], [t1].[Region], [t1].[PostalCode], [t1].[Country], [t1].[Phone], [t1].[Fax]
    FROM (
        SELECT ROW_NUMBER() OVER (ORDER BY [t0].[ContactName]) AS [ROW_NUMBER], [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactTitle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Country], [t0].[Phone], [t0].[Fax]
        FROM [dbo].[Customers] AS [t0]
        ) AS [t1]
    WHERE [t1].[ROW_NUMBER] BETWEEN 40 + 1 AND 40 + 10
    ORDER BY [t1].[ROW_NUMBER]

Comune qui su SO

Per rispondere esattamente:

ISNULL può facilmente dare risultati diversi, come COALESCE in SQL Server a causa del tipo di dati la precedenza, come per il mio risposta / commenti qui

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top