Copy Rows from TABLE 1 to TABLE 2
Volgens mij zou dit moeten lukken, maar doet het dus niet:
REPLACE INTO table_1 (id,name)
VALUES (SELECT id, name, max(ts) FROM table_2 WHERE id=99 GROUP BY id)
Ik vermoed dat het probleem ligt bij de max(ts), dit is een derde kolom bij table_2 omdat ik telkens de laatste versie wil.. Heeft iemand hier een oplossing voor aub?
Verder is de SELECT-query gewoon fout en wiskundig onmogelijk, je kunt niet de maximale waarde opvragen en daar lukraak een naam bij gaan gokken. Dat MySQL deze onzin accepteert en uitvoert, zegt meer over de gebreken van MySQL dan over de juistheid van het resultaat...
1) Ga je server fatsoenlijk configureren
2) Leer SQL
3) Misschien is het handiger om MySQL weg te flikkeren, ben je in één keer van een hoop gedonder verlost. Neem PostgreSQL, FireBird, Oracle of wat dan ook, maar alles is beter dan de MySQL-rommel.
Ps. Het kopieeren van data duidt 9 van de 10 keer op een fout datamodel, controleer dat ook nog even heel erg goed.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Hoe, je hoort geen VALUES te noemen? Je moet één tabel toch koppelen aan het ander?
Ik zie ECHT niet wat er wiskundig fout is trouwens.. Misschien is PostgreSQL nog niet tot dit niveau gevorderd?
Verder:
1) Is fatsoenlijk geconfigureerd, dank je.. Ik zie verder niet wat dit met iets te maken heeft.
2) Wanneer kan je van iets zeggen dat je het beheerst?
3) Oracle vind ik een beetje ovedreven hoor. PostslakSQL, nee dank je.
Tabel2 is een backup tabel, een extensie die ik gebruik geeft in zeldzame gevallen een exception waardoor velden worden vervangen door lege rijen. Ik heb dit al zo goed mogelijk proberen op te vangen, maar omdat ik het niet kan reproduceren zal het trial en error worden. Ik hoef mij hierover trouwens niet te verantwoorden.
Toch bedankt voor je input.
Gewijzigd op 01/01/1970 01:00:00 door Will
2) Zie punt 1, je schrijft queries die niet kunnen, jouw kennis over het gebruik van aggregate functies (max in dit geval) schiet blijkbaar te kort. Je moet zowel het id als de name in de GROUP BY benoemen.
3) Alles is beter dan MySQL, zelfs Access... PostgreSQL is trouwens ongeveer een keer zo snel als MySQL onder enige belasting, dus om dan pgSQL een slak te noemen, wat is MySQL dan wel niet? Zo snel als dikke poep door een trechter? Geeft ook goed weer wat er uit MySQL komt...
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
INSERT INTO
tabel (
id, naam
)
SELECT
id,
naam
FROM
andere_tabel
WHERE
id = 99
tabel (
id, naam
)
SELECT
id,
naam
FROM
andere_tabel
WHERE
id = 99
Verder vermoed ik dat je beter af bent met het gebruik van een trigger, dat geeft je veel meer zekerheid over de juistheid van de data wanneer je de data in 2 tabellen hebt staan. Maakt het bijhouden van de backup-tabel een heel stuk eenvoudiger.
Quote:
Misschien is PostgreSQL nog niet tot dit niveau gevorderd?
;)
MySQL heeft slechts een fractie van de functionaliteit, snelheid en betrouwbaarheid van PostgreSQL. Zie de handleidingen van beide databases.
Postgresql zal dit als fout bestempelen (ook niet meer dan logisch, je bent er namelijk niet zeker van welke rij er geselecteerd zal worden).
MySql is inderdaad veel sneller in de MyIsam modus, maargoed, dit kun je qua functioniteit en dataveiligheid niet vergelijken met Postgresql. Als je InnoDb zou gebruiken dan wordt de functionaliteit en data integriteit al beter gewaarborgd, maar dan lever je ook flink in aan snelheid.
Dat rijen willekeurig verwijderd worden zou heel goed te maken kunnen hebben met een geval als de query in je startpost.
storeman schreef op 18.12.2008 17:01:
En niet alleen PostgreSQL, andere databases keuren dit ook af. Het is wiskundig namelijk gewoon fout, je kunt niet een eigenschap van 1 enkel gegeven op een complete groep gegevens projecteren. Dat gaat gewoon niet.Postgresql zal dit als fout bestempelen (ook niet meer dan logisch, je bent er namelijk niet zeker van welke rij er geselecteerd zal worden).
Quote:
MySQL is iets sneller (zo'n 10%) wanneer er maar enkele gebruikers zijn, met 5 tot 10 gelijktijdige gebruikers houdt het al op en kakt de performance volledig in. PostgreSQL begint dan net op stoom te komen en gaat rustig door. Met een honderd gelijktijdige gebruikers presteert pgSQL al snel een keer zo veel (200%) dan MySQL. Tweakers.net heeft dit diverse keren getest op een redelijke database en keer op keer kwamen daar dezelfde verschillen naar voren.MySql is inderdaad veel sneller in de MyIsam modus
Het is niet dat PostgreSQL zo vreselijk goed is, MySQL is gewoon zo vreselijk slecht (met een standaard configuratie die bij 999 van de 1000 configuraties voorkomt). Het is dat vele programmeurs nog veel slechter zijn dat men dit niet ziet of wil zien. Je kunt een MySQL-database maar zelden vertrouwen. En dat zou nu net de basis van een DBMS moeten zijn, vertrouwen in de data en de resultaten...
Maar ga de boel nu maar configureren, dat krijg je in elk geval betere resultaten.
Ik ben het met je eens, toch is de praktijk soms weerbarstig, want tweakers.net inclusief forum draait allemaal nog op MySQL en dan hebben we het toch over een site met véél pageviews en véél data. Natuurlijk is caching hier de essentie, maar ondanks MySQL ben ik vol lof over die site. (geen idee hoe de beheerders er tegenaan kijken).
Het mooie van hun tests is overigens ook dat hun MySQL-database flink is geoptimaliseerd en dat hun pgSQL-test-database niet/nauwelijks is geoptimaliseerd. Wanneer ze deze verder zouden optimaliseren, zou het verschil met MySQL waarschijnlijk nog veel groter worden.