Eindelijk fatsoenlijke FK's in MySQL(4)

[Femme]

Hier zat ik op te wachten (MySQL 4.0.2 changelog):

# InnoDB now retains foreign key constraints through ALTER TABLE and CREATE/DROP INDEX.
# InnoDB now allows foreign key constraints to be added through the ALTER TABLE syntax.

Nu staat niets meer in de weg om foreign key constraints op een prettige manier in MySQL te gebruiken. Gezien de hoeveelheid bugfixes in MySQL 4.0.2 lijkt het erop dat MySQL 4.0 snel stabiel (beta) gemaakt zal worden en dat men daarna verder gaat met de ingrijpende vernieuwingen in 4.1 (storect procedures enzo).

* Femme kijkt (bijna) elke dag vol verwachting of er nog iets interessants is veranderd in de MySQL changelog.

[ACM]

Grappig

Ik meende dat jij zo'n tegenstander van Foreign Key's was?

Maar het is natuurlijk nog steeds maar afwachten of het ook zo goed gaat werken als zij beweren.
Ik ben er nog steeds erg sceptisch onder, dat de foreign-key support door het opslag systeem wordt bewaakt is tot daar aan toe.
Maar dat door het veranderen van het opslag systeem de foreign key ondersteuning ineens verdwijnt is natuurlijk bizar.

Verder wil ik wel es zien hoe mysql gaat werken onder de foreign key load.
Veel DB's worden er slomer van, dit omdat er allerlei extra checks uitgevoerd moeten worden. MySQL zal er dus ook slomer van worden, maar hoeveel?

[raptorix]

Joepie Nu nog Stored Procedures, Triggers, Views, en Mysql mag meeknikkeren met de grote jongens

[Femme]

Volgens de InnoDB manual komen de verbeteringen ook beschikbaar in MySQL 3.23.50.

Ik meende dat jij zo'n tegenstander van Foreign Key's was?

Ik heb gezegd dat het gemis van FK's bij bepaalde toepassingen niet opweegt tegen het aanschaffen van een Oracle licentie (of het lozen van een open source db waar een developer ervaring mee heeft vs een open source db met FK's die helemaal groen is voor de devver) .

[Infinitive]

PostgreSQL begint de laatste tijd toch ook wel wat populairder te worden. Dit ondersteunt wel de hele mikmak, maar dat gaat dan wel ten koste van de performance (en in dat laatste geval mag postgres toch nog wel wat verbeterd worden).

Maar de FK's net zoals de transacties alleen met InnoDB tables?

[Orphix]

Op donderdag 28 maart 2002 01:27 schreef Infinitive het volgende:
PostgreSQL begint de laatste tijd toch ook wel wat populairder te worden. Dit ondersteunt wel de hele mikmak, maar dat gaat dan wel ten koste van de performance (en in dat laatste geval mag postgres toch nog wel wat verbeterd worden).

Maar de FK's net zoals de transacties alleen met InnoDB tables?

# InnoDB now retains foreign key constraints through ALTER TABLE and CREATE/DROP INDEX.
# InnoDB now allows foreign key constraints to be added through the ALTER TABLE syntax.

Mwoahja ik verwacht het wel

Als MySQL beetje slim is gaan ze gewoon van InnoDB een full-featured db systeem maken en dan kan je altijd nog MyISAM tabellen gebruiken voor full speed. Het beste van 2 werelden heb je dan.

[xoror]

is dat count( * ) probleem beetje opgelost met innodb ?
lijk me wel interessant hoe ze dat doen. met MVCC is het namelijk heel lastig bij te houden.

pgsql heeft daar ook een sequential scan op een table voor nodig.

[dusty]

Nog even en ze kunnen MySQL een echte database gaan noemen

[jochemd]

Op donderdag 28 maart 2002 00:58 schreef Femme het volgende:

...
(of het lozen van een open source db waar een developer ervaring mee heeft vs een open source db met FK's die helemaal groen is voor de devver) .

Wat maakt dat nou uit? Misschien voor de administrator, maar voor een developer toch niets? Tenzij één van de databases zich qua syntax niet aan de relevante SQL standaarden houdt natuurlijk

* jochemd kijkt uit naar de dag dat || een concatenation operator is in MySQL

[ACM]

Op donderdag 28 maart 2002 11:10 schreef jochemd het volgende:
Wat maakt dat nou uit? Misschien voor de administrator, maar voor een developer toch niets? Tenzij één van de databases zich qua syntax niet aan de relevante SQL standaarden houdt natuurlijk

En _dat_ is nou gelijk het nadeel van MySQL het houdt zich op sommige punten van geen kanten aan de standaard.

Sinds wanneer is een 'a' gelijk aan een 'A' Standaard mag je helemaal niet defaults aanmaken als je die niet opgeeft... Wat doet mysql? Geeft je verplicht een setje defaults, zelfs op een NULL row.
En noem maar op.

Zelf ben ik trouwens redelijk tot behoorlijk ervaren met postgres dus das een slechte smoes van Femme, de conversie hoeft tenslotte niet van de ene op de andere dag te gebeuren

_{(maar Femme's keuze op mysql te blijven werken is natuurlijk niet alleen maar ingegeven door zijn gebrek aan ervaring met andere DBMS-en)}

[justmental]

Op donderdag 28 maart 2002 00:58 schreef Femme het volgende:
Ik heb gezegd dat het gemis van FK's bij bepaalde toepassingen niet opweegt tegen het aanschaffen van een Oracle licentie

Qua FK's ben ik het met je eens, maar dat is maar een heel klein stukje van de ontbrekende functionaliteit in MySQL.

(of het lozen van een open source db waar een developer ervaring mee heeft vs een open source db met FK's die helemaal groen is voor de devver) .

Daar komt de aap uit de mouw
De devver blijft bij wat ie kent

Wordt de SQL support inmiddels al beter (subqueries/unions etc)?

[xoror]

trouwens, mysql kan niet eens case sensitive zoeken he ?
of vergis ik me? mysql behandelt alle cases gelijk of niet?

Zelf ben ik trouwens redelijk tot behoorlijk ervaren met postgres dus das een slechte smoes van Femme, de conversie hoeft tenslotte niet van de ene op de andere dag te gebeuren

eheh dan ben je vast blij met dit http://www.ca.postgresql.org/ftpsite/latest/postgresql-7.2.1.tar.gz

edit:
oeps, 7.2.1 moest het zijn

[ACM]

Op donderdag 28 maart 2002 11:27 schreef xoror het volgende:
trouwens, mysql kan niet eens case sensitive zoeken he ?
of vergis ik me? mysql behandelt alle cases gelijk of niet?

Ja dat kan wel... Maar daar moet je allerlei gekke handelingen voor zoeken (veld op binairy zetten (waar is dat onderscheid nou voor nodig ) of expliciet opgeven dat je casesensitive _wilt_ zoeken) etc zie ook al mijn reply eerder

Verder is het allerbelachelijkste natuurlijk die casesensitiveness van de tabelnamen versus niet casesensitive zoeken op teksten

Op donderdag 28 maart 2002 11:27 schreef xoror het volgende:
eheh dan ben je vast blij met dit

Lol, in een testopstelling thuis draai ik al posgres 7.2 hoor
En voor de liefhebbers, hij is sneller dan Firebird 1.0 in mijn opstelling

[edit]
Humm, synchroon editten?
Maar 7.2.1 zal ik gelijk es downloaden

[xoror]

trouwens postgresql performt echt prima met veel records.
heb voor school search engine moeten bakken. zoek tijden waren prima (wel met stored procs gedaan).

[xoror]

Lol, in een testopstelling thuis draai ik al posgres 7.2 hoor
En voor de liefhebbers, hij is sneller dan Firebird 1.0 in mijn opstelling

untuned pgsql ? je kan pgsql stukken rapper maken door wat aanpassingen te doen in je postgresql.conf

[ACM]

Op donderdag 28 maart 2002 11:31 schreef xoror het volgende:
trouwens postgresql performt echt prima met veel records.
heb voor school search engine moeten bakken. zoek tijden waren prima (wel met stored procs gedaan).

Wat bedoel je daar precies mee?
Dat je veel records terug krijgt of veel records afgaat?

Een miljoen records aflopen (ok, rows met weinig aan tekst maar toch) doet mysql hier toch wel 4x zo snel als postgres geloof ik.

Maar als je echt veel vervolg queries uitvoert zal het idd vanzelf sneller worden als je stored procs kan gebruiken

Op donderdag 28 maart 2002 11:33 schreef xoror het volgende:
untuned pgsql ? je kan pgsql stukken rapper maken door wat aanpassingen te doen in je postgresql.conf

Tuned, ik had de query tijd al van 0.63 naar 0.27 seconden terug gebracht in een bepaald geval

Maar als jij denkt dat ie nog verder getuned kan worden... Hoor ik het graag
(mede door vacuum full analyze uit te voeren trouwens)

[xoror]

Maar als jij denkt dat ie nog verder getuned kan worden... Hoor ik het graag
(mede door vacuum full analyze uit te voeren trouwens)

vacuum full hoef je alleen te doen als er HEEL veel data is geinsert/verwijderd/gewijzigd. meestal doe je dat 1x per nacht ofzo. er is ook een "analyze" command. kan je even snel doen om queries te testen.

je kan sort_mem, shared_mem etc omhoogschroeven.
standaard staan ze beetje conservatief. zie : http://www.phpbuilder.com/columns/smith20010821.php3
en http://developer.postgresql.org/docs/postgres/performance-tips.html

let ook op dat je als je indices gebruikt, ook checked of ze gebruikt worden. (explain ..). als ie je index niet used, moet je ff analyze; doen.

en verder it's all about indices, ik heb getest met table van 2 miljoen records. als de indices goed staan en als ze gebruikt worden, is ie super snel.

code:

select count(*) from wordlist;
 count  
--------
 419830
(1 row)

select count(*) from worddoclist;
  count  
---------
 2528626
(1 row)

select * from wordlist,worddoclist where word_id = id and word = 'BLA';
NOTICE:  QUERY PLAN:

Nested Loop  (cost=0.00..56.49 rows=6 width=48)
  ->  Index Scan using wordlist_word_key on wordlist  (cost=0.00..4.40 rows=1 width=24)
  ->  Index Scan using worddoclist_word_id_key on worddoclist  (cost=0.00..51.94 rows=13 width=24)

EXPLAIN

zoals je ziet zijn de cost echt vrijwel nihil. (56 units ofzo en dit is ook trage bak).
[edit example toegevoegd]

[PhoneTech]

En dan nu maar hopen dat ze een keer van naam veranderen...Ik vind mySQL een beetje knullig klinken...

Het klinkt als je er alleen persoonlijke dingen mee kan doen...Terwijl met versie 4 ze redelijk met de grote jongens kan mee draaien...

Dus ik stel voor dat mySQL maar eens opzoek gaat met een nieuwe krachtige naam!

dus...

[ACM]

Op donderdag 28 maart 2002 11:40 schreef xoror het volgende:
je kan sort_mem, shared_mem etc omhoogschroeven.
standaard staan ze beetje conservatief.

Die had ik beide al omhoog gezet idd

zoals je ziet zijn de cost echt vrijwel nihil. (56 units ofzo en dit is ook trage bak).

MySQL kent ook indices
Maar idd, hoe groter de indices hoe kleiner het verschil tussen mysql en postgres zal worden gok ik

[.oisyn]

Ter ere van van het verdwijnen van Webwereld (nieuws: Nederlandse techsite Webwereld stopt), sluit ik dit topic van @Femme (zie artikel voor context ).

Press F to pay respects.

[Woy]

F