Non so niente di Oracle, ma dal momento che la questione è stata ampliata per includere, per esempio, Postgres ...
alcune cose che ho usato personalmente o visto usare in Postgres che non esistono realmente in MySQL (AFAICT)!
- transazioni e ricerca full-text insieme
So che è popolare per utilizzare un FTS esterni poiché MySQL non ne ha uno. Personalmente, non ho avuto altro che problemi nell'utilizzo di soluzioni FTS separate: se è possibile che le due origini dati non siano sincronizzate, posso garantire che a un certo punto lo faranno. Potrei usare BDB e scrivere anche i miei indici, ma non lo faccio, perché non vedo in che modo sia migliore di un indice incorporato e un sacco di modi in cui è peggio. (OK, in un caso avevo bisogno di un indice personalizzato strano, e per questo è bello.Se hai bisogno di un FTS personalizzato strano, allora forse Sphinx è più flessibile, ma non ho mai visto un reale bisogno di uno strano FTS personalizzato, e io non sono nemmeno sicuro che Sfinge è più flessibile di Postgres FTS.)
query
non so se MySQL ha un meccanismo di estensione che permette questo, ma io Sono abbastanza sicuro che non abbia un'estensione come PostGIS. Supponiamo che tu voglia interrogare tutte le caffetterie entro 300 metri da un parco, e non entro 100 metri da una discarica (dato che il tuo database ha i confini di parchi, discariche e caffetterie). È straordinariamente facile con PostGIS. Con MySQL, penso che probabilmente sarebbe una buona quantità di lavoro.
- tabelle relazionali a oggetti
Rails persone (hey, ho usato per essere uno!), In particolare, piace usare STI e fingere che tutte le sottoclassi hanno più o meno gli stessi campi della superclasse. Va bene se hai solo un paio di sottoclassi o sono tutte molto simili, ma provare a mappare una gerarchia di classi in tabelle può diventare abbastanza folle abbastanza velocemente. In Postgres, è facile: creare una nuova tabella che erediti dal primo e aggiunge i suoi campi, proprio come la sottoclasse nel tuo linguaggio di programmazione. Un modello di dati che corrisponde effettivamente ai miei dati! Non bello come un vero OODB ma piuttosto dannatamente vicino.
So che se si bastone con InnoDB si ottiene transazioni per tutte le operazioni di manipolazione dei dati. Postgres ha anche transazioni per tutte le operazioni definizione dei dati operazioni. Prendiamo un caso comune: ho bisogno di una migrazione per aggiungere una colonna, convertire i dati dal vecchio formato nel nuovo formato e rimuovere una vecchia colonna. In Postgres, faccio tutto tutto in un'unica transazione, e non ho alcuna possibilità che finisca con questa transazione parzialmente applicata.In MySQL, può fare il passaggio di conversione dei dati in una transazione, certo, ma se deve essere ripristinato, la nuova colonna è stata ancora aggiunta, quindi è necessario pulirla manualmente o scrivere una transazione più complessa da gestire quello (e anche allora non è ancora atomico nel db). Ripeti ogni giorno e goditi il dolore.
(Il tema generale che vedo qui è la capacità di dire esattamente cosa intendo, e quindi lavorare a un livello più alto di astrazione. Vuoi FTS sui miei dati? Quindi creare un indice FTS. Vuoi una query spaziale? una query spaziale: vuoi memorizzare i dati di sottoclassi ?, quindi creare una tabella di sottoclassi. Vuoi una migrazione completamente atomica? Quindi esegui uno schiaffo su una transazione e chiamiamola un giorno. Certo, posso implementare qualcuno di questi in MySQL, ma poi I ' Devo pensare e implementare e mantenere quell'altra cosa , piuttosto che scrivere solo una singola riga di SQL. Come programmatore professionista non c'è niente di più prezioso per me che essere in grado di lavorare ad un livello più alto di astrazione, punto e basta.)
Ora, non sono sicuro se dovessi dire che Postgres è generalmente "migliore" di MySQL - ci sono certamente cose che MySQL fa molto meglio e quindi sicuramente ha i suoi usi - ma queste sono alcune cose che adoro assolutamente.
Perché Oracle è l'unica alternativa a MySql? – cjk
Vero, ha aggiornato la domanda :) –
Un buon suggerimento sarebbe quello di smettere di essere un fan di MySQL durante il processo di valutazione. | -) – jrbjazz