"MySQL database which is quite troublesome because foreign-keys are not enforced"
Not sure what this means. Innodb will enforce them and has been the default for "awhile" although if you don't configure FKs it won't automagically do it for you (superficially, a DBMS that assumed any column named user_id is a FK for table user column id, although I bet that would create some amazing bugs occasionally) If you use myisam you can hack in FKs using triggers, which is icky/foul but you only have to do it once in the design phase. Or just don't use myisam unless you need its sometimes somewhat higher speed.
Something I say a lot is its a philosophical outlook difference. Outta the box, MySQL is a cub scout who always does his best, which may or may not have anything to do with what you think is a reasonable goal. On the other hand outta the box some DB like Postgres have no sense of humor and will go on strike / curl up and die if you ask it do something somewhat imperfectly or without the proper precise etiquette. Its somewhat easy to spend some time configuring either toward your project's philosophy or your personal philosophy.
This philosophy thing is why your comparisons were insensitive... the default outta the box collation was (is?) something weird like latin1_swedish_ci and if you merely change it to latin1_general_cs or whatever it "just works" and becomes case sensitive. Well what does the helpful cub scout mysql do, it makes sure you get all the results you could possibly want, in addition to some you probably don't.
I have run into slow schema mod problem before. Solution, don't change your schema.
Not sure what this means. Innodb will enforce them and has been the default for "awhile" although if you don't configure FKs it won't automagically do it for you (superficially, a DBMS that assumed any column named user_id is a FK for table user column id, although I bet that would create some amazing bugs occasionally) If you use myisam you can hack in FKs using triggers, which is icky/foul but you only have to do it once in the design phase. Or just don't use myisam unless you need its sometimes somewhat higher speed.
Something I say a lot is its a philosophical outlook difference. Outta the box, MySQL is a cub scout who always does his best, which may or may not have anything to do with what you think is a reasonable goal. On the other hand outta the box some DB like Postgres have no sense of humor and will go on strike / curl up and die if you ask it do something somewhat imperfectly or without the proper precise etiquette. Its somewhat easy to spend some time configuring either toward your project's philosophy or your personal philosophy.
This philosophy thing is why your comparisons were insensitive... the default outta the box collation was (is?) something weird like latin1_swedish_ci and if you merely change it to latin1_general_cs or whatever it "just works" and becomes case sensitive. Well what does the helpful cub scout mysql do, it makes sure you get all the results you could possibly want, in addition to some you probably don't.
I have run into slow schema mod problem before. Solution, don't change your schema.