calicant ha scritto:cdimauro ha scritto:Per chi non c'ha mai avuto a che fare il mio consiglio è di lasciarlo perdere e passare a prodotti diversi. D'altra parte su OS4 non mancano i linguaggi, no? Python c'è sicuramente ed è ben supportato.
e lasciamo perdere anche quell' "aborto" di mysql...
hai un link anche per questo giudizio che non lascia altra via d'uscita che tirare l'acqua del cesso?
Non ho un link preciso, ma anni di esperienza. Però qualcuna grossolana te la riporto qui.
Dopo ANNI passati senza stored procedure e trigger (hai presente un engine SQL "enterprise" SENZA queste funzionalità? Beh, c'era solo MySQL prima!), finalmente con la versione 5 (dico: CINQUE; vedi da quando esiste MySQL e quando hanno rilasciato la 5, e fatti i conti) li implementano, e che sai che fanno?
Si dimenticano di inserire la possibilità di sollevare eccezioni! Chi ha programmato con questa roba sa cosa voglio dire e cosa significa questa ENORME mancanza.
Prova a creare un campo enumerativo con alcuni valori definiti, inserisci qualche record con uno di essi. Poi altera la tabella e ridefinisci l'enumerativo togliendo il valore che hai usato in precedenza, fai una SELECT e vedi adesso il record com'è fatto. Poi prova con una DELETE a cancellare quel record...
Se provi a definire una foreign key su una tabella MyISAM, MySQL non batte ciglio: non ti dà neppure un warning sul fatto che poi NON avrà effetto visto che MyISAM non supporta questa funzionalità. Per cui se impazzisci cercando di capire perché qualcosa non ha funzionato, com'è capitato a un sacco di gente, adesso sai perché.
Se esegui una TRUNCATE o una DROP TABLE su una tabella con engine che supporta l'integrità referenziale e sulla quale è definito un trigger
ON DELETE... NON SCATTA!Su MySQL in configurazione cluster NON vengono replicati i trigger sulle macchine sincronizzate...
Se cambi lo schema relazionale di una tabella, questa viene lockata, il sistema si fa una copia dei record con la nuova struttura, e alla fine dell'operazione finalmente è a disposizione. Nel frattempo TUTTI i processi che hanno cercato di farne uso sono rimasti appesi; e se la tabella contiene decine di milioni di record, beh, può anche succedere di
bloccare un database di produzione per TRE ORE.
Lo stesso capita se provi a fare un backup di una tabella o di un intero database: viene lockato tutto. Non esiste, infatti, la possibilità di eseguire un backup "trasparente", lasciando completamente operativo il sistema; c'è solo per l'engine InnoDB, ma si tratta di un prodotto commerciale e la licenza costa una vagonata di soldi.
Se utilizzi un tipo TIMESTAMP per memorizzare data e orario usando un formato compatto (occupa solo 32 bit), qualunque operazione di UPDATE aggiornerà automaticamente quel campo. E se non conosci questo comportamento subdolo, ti ritroverai coi
dati iniziali persi.
Poiché MySQL utilizza il filesystem per memorizzare le singole tabelle, il suo comportamento varia a seconda del s.o. in cui gira. Così su Unix & Linux sei COSTRETTO a utilizzare il preciso case con cui hai definito la tabella, per cui SELECT * FROM Customers funziona mentre SELECT * FROM customers NO! Ma il case sensitive funziona soltanto sui nomi delle tabelle: per tutto il resto, come lo standard SQL comanda, è case insensitive.
La cosa carina è che su Windows, dove il filesystem è case insensitive (ma case preserving), potrebbe funzionare perfettamente secondo lo standard, ma invece forza il case delle tabelle sempre a minuscolo! Lo stesso comportamento immagino lo abbia con AmigaOS e MacOS, che sono entrambi case insensitive (per fortuna).
Questa è qualche chicca, ma ce ne sono sicuramente tante altre che al momento non mi vengono.
EDIT:
samo79 ha scritto:Avviso ai naviganti, un altro post fuori tema e si chiude tutto ...
Come puoi vedere ho scritto un lungo post, e quando l'ho inviato avevi già scritto il tuo messaggio.
Comunque il topic parla di PHP e MySQL: penso sia interesse della gente che potrebbe utilizzarli capire a quali problemi possono andare incontro.
