What would they get? A company that does not work well enough, with a lot of stuff they did not want/need. It's extremely difficult to rebuild such company and they've decided it's not worth the money and risk. For Google it's easier to build their engineering department, shaped to their needs. Right, the IP stuff might be interesting for them, especially regarding this battle with Oracle, but the game is not over yet.
Yes, brainfuck is much faster [http://en.wikipedia.org/wiki/Brainfuck] and it's not bloated with the useless stuff (objects, classes, letters, digits).
Having a policy for unique menu items: YES Forcing other project to use a different application name: NO
For example the KDE would contain two menu items "System settings" and "GNOME system settings." The GNOME would contain "KDE system settings" and "System settings."
I'm a satisfied KDE user, but this complaint is absolutely ridiculous. Does that mean each system component needs a name that's unique in the whole universe?
AFAIK those are applications, not accepted patents. Or am I wrong?
And as someone already mentioned, this is not a new technique at all, it goes back to PDP-11 or maybe even to some previous systems. That might be a perfect example or prior art.
The problem with software patents is that you have to challenge them at court once they're accepted. Which can be a bit pricey and lengthy process, especially if the owner is a big company with zillions of lawyers as Oracle. So I'd expect the other interested parties (Red Hat, etc.) will fight to prove the patents are nonsense. Actually much harder now when Oracle bought the company...
The fact that HTC decided to pay Apple some fee does not prove they've violated their IP. It merely means they've found out this was a cheaper and safer way to go. Maybe they'd loose, paying 10x more, maybe they'd win but paying a lot of money to the lawyers...
Most of the Apple patents are complete gibberish, a perfect proof that software patents are just a stick used to bash competitors.
Prepare a few millions to pay the lawyers. AFAIK Google knew they're using technology owned by Sun, decided to play and will and it worked fine for a few years. But they're probably end like a dupe in a casino, loosing 10x they've gained.
Why is that shitty, exactly? I'm not saying I love Oracle, but the ability to fork is one of the great freedoms with open source - not that every company should breed their own distro, but it's not necessarily bad. Oracle's politics is to sell products with their logos on the box so they resell Red Hat. BTW it's not true they're not giving anything back - according to the stats, they're usually in TOP10 companies (see http://www.remword.com/kps_result/). So while I don't like Oracle for a lot of various reasons, I don't think they're not giving back.
Yes, they're keeping some know how, but RH does something very similar with patches (they provide much more to their customers). And you don't have to use their Oracle Linux at all (unless you're too weak when dealing with Oracle sales guys). For example the largest local bank uses plenty of Oracle DB instances on top of RH Linux (and HP Unix), but not a single Oracle Linux install AFAIK.
And this whole KSplice topic is a bit silly - they've bought the engineering team, but the tool is open source. Yes, they'll probably change the license etc. but they have the right to do that and we should respect that. We always knew this can happen, after all the KSplice was a company, not a bunch of our slaves. And the tools is open source, so if it was so valuable for other distros, someone will create a fork. If no one forks it, it probably was not that important.
Well, many attacks are based on unexpected values (if the developer expected that and it fails, he's a bit stupid). I was just pointing out this is not exactly SQL injection - the difference is that in this case there was a piece of business logic missing (check that the user is authorized to do that) and in case of SQL injection it's a failure at much lower level (data access).
Anyway, let's not argue about this and let's read some old XKCD strips we've already forgotten.
An awful lot of sites depend on visitors from search engines. No visitors = no business, so if you can block competing sites from the index (and thus from results), your business will be hurt badly.
SERIALIZABLE is not truly guaranteeing anything. A common misunderstanding is that SERIALIZABLE is equal to running the transactions in a serial fashion. That is not true! Those levels are defined using phenomena (dirty reads, non-repeatable reads and phantom reads) or rather lack of those phenomena. But that does not mean there are no other problems - the ANSI just decided those three and defined the isolation levels. There are other phenomena / dependencies that make the transactions 'not serializable'.
The only DB (I'm aware of), implementing true SSI (Serializable Snapshot Isolation) is the upcoming PostgreSQL 9.1. See this http://wiki.postgresql.org/wiki/SSI
They have probably noticed the end of the world is December 21, 2012 and they hope it's true. That way no one will actually notice Hurd was postponed again...
I love synonyms. And you are right, it is probably that I am thinking of (possibly because I always thought of synonyms as a form of permission since when I have used them we make sure table names never overlapped between schemas... or very little anyway). I don't like the search path method as I never seem to get it right... I would love to see synonyms in Postgres.
Well, it's a very different concept and if you're used to synonyms it's going to feel strange. I work with Oracle too and while I like synonyms I don't think they're somehow superficial to search_path (or vice versa).
Anyway, I also want to say that if you modify hbaconf to allow a DBA to create users from anywhere, it means you aren't limiting anyone via hbaconf from connecting to the database. In that case hbaconf is meaningless and not needed. Especially as all O/S's provide the same functionality (limiting access to the box).
I've just wanted to point out that the need to modify the pg_hba.conf is not very frequent and in some cases you may configure it so that you don't need to modify it at all. It's just a way to define access rules outside the database. Maybe I'm missing something but I still don't see a problem with this approach.
Where I've worked with HA, the volumes are so high that if you wait for a DBA to verify whether it should cut over or not, the company can lose literally millions of dollars (systems with no exaggeration, up to hundreds of millions of accounts). i.e. Even if the switch was done because someone unplugged a network cable and the primary never actually went down. The primary should be able to become the secondary once the cable is reattached (since the secondary is now the primary).
With the built-in replication, it's a bit difficult to turn primary to a slave (I'm not aware of a way/tool to do that and I suspect it's not possible, but maybe I'm wrong). With slaves this is possible, i.e. you may promote one slave to primary and switch the other one to follow it (instead of the old primary).
Often the primary/secondary are in the same general location and network because it is more likely that one will go down due to hardware problems than because of natural disasters requiring a remote backup server. In these cases sync issues are not an issue and if they are, then the system is not adequate to your needs. I agree a DBA should investigate if for some reason a remote slave (placed remote in case of environmental disaster) wants to try to take over, but not for the very much more common local primary/secondary set up.
I don't think there's a big difference between local and remote replication, although keeping a slave at a different location makes certain kind of problems more likely (I've seen cables nicely cut with a digger, data centers that went completely down because of failed ups, we had floods here a few years ago, etc.) but even with a single site you need two separate network paths (what if a switch fails?). And it's very easy to end with two machines thinking they're primary. That's a classical network partitioning problem and it may do a lot of harm...
But sure - there are cases where automatic failover is probably the right thing to do, no doubt about that. I'm just saying it's very difficult to implement that in a sufficiently generic way - that's one of the nice things on PostgreSQL that you may configure it to your needs. The "unix mentality" of the development means there won't be any such "complete HA solution" anytime soon, but I do expect external packages to do the same thing (I've already mentioned repmgr) and some might move to contrib eventually.
Aaaaarghhhhh, submitted before noticing the whole post is a single paragraph. So once again in a bit more legible form:
Yes, the HA stuff is not as nicely wrapped as in other databases and may require a bit of work (e.g. to write a script). There are two main reasons for that - first, the replication stuff is about 1 year old and the developers prefer to build just very basic functionality first and see how that works. Second, the developers tend to have "unix mentality" i.e. they prefer to build tools that are easy to extend with other tools (as with "|" in the unix shell). So there's just a bare replication stuff, they're improving it where needed (e.g. the monitoring is going to be much better in 9.1, synchronous replication was added etc.), and some of the stuff has to be implemented in external tools (e.g. the management utilities - repmgr looks really promising).
I personally don't see the need to write a script as a major obstacle, for me it's a big advantage. I work in this area for a few years and I'm really sick of those nice GUI management tools, because with a reasonably complex environment you'll have to log into multiple such tools, click a few buttons and so on. That's manual work, it's takes time and it's error prone. A simple script is much more reliable for us and it's really easy to integrate into other scripts.
And the automatic failover - I really don't like fully automatic jobs in most cases. I've seen so many cases when this backfired I prefer a solution that gives the admin an opportunity to verify failover really is the right thing to do. For example when replicating to different location, there're so many possible reasons why the master might be unavailable and the slave might belive it's time to become master... But even when such automatic failover should happen, it's usually pretty simple to script that does it.
Not sure what you find tedious on the security... For me it's pretty straigtforward, and actually you don't need to modify the config file when creating a new user in most cases. I usually set it once at the beginning, stating something like 'remote users need to provide password, local users can access without password' or something like that. And then you don't need to touch it for a year, then someone wants to add kerberos for some users or something like that - a simple edit.
I'm a really confused by the rest of your post, because schemas are threated almost exactly as you describe. It seems you've missed the 'search_path' that allows you to define a list of schemas - the objects are searched in those schemas and the first matching object is returned. So you don't have to prepend the object name with a schema name, just set the search_path properly.
BTW I'm not aware of a database that searches for the object in all schemas the user has permissions on - e.g. Oracle searches in the "current schema" only and you have to create synonyms to access objects in other schemas this way. Try to create two users, create a table in one of them, grant privileges on the table to the other user and let the other user select data from it (without referencing the schema name) - doesn't work. You have to create a synonym. You can create a 'invoke rights' procedure, but even that one resolves the objects this way. (With search_path this can be done quite easily, just put there more schema names.)
Actually this makes the application a bit fragile - say there are three applications in separate schemas A, B and C. Application A uses table X in schema C without schema name. Then the application C is extended with a table X - ooops, the application suddenly does not work, because it references the wrong table.
Yes, the HA stuff is not as nicely wrapped as in other databases and may require a bit of work (e.g. to write a script). There are two main reasons for that - first, the replication stuff is about 1 year old and the developers prefer to build just very basic functionality first and see how that works. Second, the developers tend to have "unix mentality" i.e. they prefer to build tools that are easy to extend with other tools (as with "|" in the unix shell). So there's just a bare replication stuff, they're improving it where needed (e.g. the monitoring is going to be much better in 9.1, synchronous replication was added etc.), and some of the stuff has to be implemented in external tools (e.g. the management utilities - repmgr looks really promising).
I personally don't see the need to write a script as a major obstacle, for me it's a big advantage. I work in this area for a few years and I'm really sick of those nice GUI management tools, because with a reasonably complex environment you'll have to log into multiple such tools, click a few buttons and so on. That's manual work, it's takes time and it's error prone. A simple script is much more reliable for us and it's really easy to integrate into other scripts.
And the automatic failover - I really don't like fully automatic jobs in most cases. I've seen so many cases when this backfired I prefer a solution that gives the admin an opportunity to verify failover really is the right thing to do. For example when replicating to different location, there're so many possible reasons why the master might be unavailable and the slave might belive it's time to become master... But even when such automatic failover should happen, it's usually pretty simple to script that does it.
Not sure what you find tedious on the security... For me it's pretty straigtforward, and actually you don't need to modify the config file when creating a new user in most cases. I usually set it once at the beginning, stating something like 'remote users need to provide password, local users can access without password' or something like that. And then you don't need to touch it for a year, then someone wants to add kerberos for some users - a simple edit.
I'm a really confused by the rest of your post, because schemas are threated almost exactly as you describe. It seems you've missed the 'search_path' that allows you to define a list of schemas - the objects are searched in those schemas and the first matching object is returned. So you don't have to prepend the object name with a schema name, just set the search_path properly.
BTW I'm not aware of a database that searches for the object in all schemas the user has permissions on - e.g. Oracle searches in the "current schema" only and you have to create synonyms to access objects in other schemas this way. Try to create two users, create a table in one of them, grant privileges on the table to the other user and let the other user select data from it (without referencing the schema name) - doesn't work. You have to create a synonym. You can create a 'invoke rights' procedure, but even that one resolves the objects this way.
Actually this makes the application a bit fragile - say there are three applications in separate schemas A, B and C. Application A uses table X in schema C without schema name. Then the application C is extended with a table X - ooops, the application suddenly does not work, because it references the wrong table.
The ACID does not imply that the database has to support foreign keys. A RDBMS may be ACID compliant and not to support referential integrity. It just says that if it does, it must enforce it properly.
I'm not saying I like RDBMS that lack FKs. I was just a bit afraid you believe "relational = allows to create relations between tables (FK)" - I've heard that nonsense too often.
Slashdot Mirror
What would they get? A company that does not work well enough, with a lot of stuff they did not want/need. It's extremely difficult to rebuild such company and they've decided it's not worth the money and risk. For Google it's easier to build their engineering department, shaped to their needs. Right, the IP stuff might be interesting for them, especially regarding this battle with Oracle, but the game is not over yet.
Yes, brainfuck is much faster [http://en.wikipedia.org/wiki/Brainfuck] and it's not bloated with the useless stuff (objects, classes, letters, digits).
With most recent movies, 2D hurts too. But that's mostly because of screenplay.
Having a policy for unique menu items: YES
Forcing other project to use a different application name: NO
For example the KDE would contain two menu items "System settings" and "GNOME system settings." The GNOME would contain "KDE system settings" and "System settings."
Why "Open" and "File"? Should those be UUIDs too? Just to be sure there are no duplicate menu items ;-)
I'm a satisfied KDE user, but this complaint is absolutely ridiculous. Does that mean each system component needs a name that's unique in the whole universe?
AFAIK those are applications, not accepted patents. Or am I wrong?
And as someone already mentioned, this is not a new technique at all, it goes back to PDP-11 or maybe even to some previous systems. That might be a perfect example or prior art.
The problem with software patents is that you have to challenge them at court once they're accepted. Which can be a bit pricey and lengthy process, especially if the owner is a big company with zillions of lawyers as Oracle. So I'd expect the other interested parties (Red Hat, etc.) will fight to prove the patents are nonsense. Actually much harder now when Oracle bought the company ...
And those appeals will be appealed, etc.
Can you imagine a world without lawyers? http://www.youtube.com/watch?v=0u9JAt6gFqM
The fact that HTC decided to pay Apple some fee does not prove they've violated their IP. It merely means they've found out this was a cheaper and safer way to go. Maybe they'd loose, paying 10x more, maybe they'd win but paying a lot of money to the lawyers ...
Most of the Apple patents are complete gibberish, a perfect proof that software patents are just a stick used to bash competitors.
Prepare a few millions to pay the lawyers. AFAIK Google knew they're using technology owned by Sun, decided to play and will and it worked fine for a few years. But they're probably end like a dupe in a casino, loosing 10x they've gained.
Why is that shitty, exactly? I'm not saying I love Oracle, but the ability to fork is one of the great freedoms with open source - not that every company should breed their own distro, but it's not necessarily bad. Oracle's politics is to sell products with their logos on the box so they resell Red Hat. BTW it's not true they're not giving anything back - according to the stats, they're usually in TOP10 companies (see http://www.remword.com/kps_result/). So while I don't like Oracle for a lot of various reasons, I don't think they're not giving back.
Yes, they're keeping some know how, but RH does something very similar with patches (they provide much more to their customers). And you don't have to use their Oracle Linux at all (unless you're too weak when dealing with Oracle sales guys). For example the largest local bank uses plenty of Oracle DB instances on top of RH Linux (and HP Unix), but not a single Oracle Linux install AFAIK.
And this whole KSplice topic is a bit silly - they've bought the engineering team, but the tool is open source. Yes, they'll probably change the license etc. but they have the right to do that and we should respect that. We always knew this can happen, after all the KSplice was a company, not a bunch of our slaves. And the tools is open source, so if it was so valuable for other distros, someone will create a fork. If no one forks it, it probably was not that important.
Well, many attacks are based on unexpected values (if the developer expected that and it fails, he's a bit stupid). I was just pointing out this is not exactly SQL injection - the difference is that in this case there was a piece of business logic missing (check that the user is authorized to do that) and in case of SQL injection it's a failure at much lower level (data access).
Anyway, let's not argue about this and let's read some old XKCD strips we've already forgotten.
Ooops, I see. Probably an attempt to gain some traffic ...
An awful lot of sites depend on visitors from search engines. No visitors = no business, so if you can block competing sites from the index (and thus from results), your business will be hurt badly.
The bug in webmaster tools has nothing to do with SQL injection, so although I like XKCD the two posts are quite irrelevant.
SERIALIZABLE is not truly guaranteeing anything. A common misunderstanding is that SERIALIZABLE is equal to running the transactions in a serial fashion. That is not true! Those levels are defined using phenomena (dirty reads, non-repeatable reads and phantom reads) or rather lack of those phenomena. But that does not mean there are no other problems - the ANSI just decided those three and defined the isolation levels. There are other phenomena / dependencies that make the transactions 'not serializable'.
See this excellent post on this topic http://iggyfernandez.wordpress.com/2010/09/20/dba-101-what-does-serializable-really-mean/
The only DB (I'm aware of), implementing true SSI (Serializable Snapshot Isolation) is the upcoming PostgreSQL 9.1. See this http://wiki.postgresql.org/wiki/SSI
Really? They've promised to deliver this in 2012 twenty years ago? I remember they always promised to deliver it 'next year'.
They have probably noticed the end of the world is December 21, 2012 and they hope it's true. That way no one will actually notice Hurd was postponed again ...
I love synonyms. And you are right, it is probably that I am thinking of (possibly because I always thought of synonyms as a form of permission since when I have used them we make sure table names never overlapped between schemas... or very little anyway). I don't like the search path method as I never seem to get it right... I would love to see synonyms in Postgres.
Well, it's a very different concept and if you're used to synonyms it's going to feel strange. I work with Oracle too and while I like synonyms I don't think they're somehow superficial to search_path (or vice versa).
Anyway, I also want to say that if you modify hbaconf to allow a DBA to create users from anywhere, it means you aren't limiting anyone via hbaconf from connecting to the database. In that case hbaconf is meaningless and not needed. Especially as all O/S's provide the same functionality (limiting access to the box).
I've just wanted to point out that the need to modify the pg_hba.conf is not very frequent and in some cases you may configure it so that you don't need to modify it at all. It's just a way to define access rules outside the database. Maybe I'm missing something but I still don't see a problem with this approach.
Where I've worked with HA, the volumes are so high that if you wait for a DBA to verify whether it should cut over or not, the company can lose literally millions of dollars (systems with no exaggeration, up to hundreds of millions of accounts). i.e. Even if the switch was done because someone unplugged a network cable and the primary never actually went down. The primary should be able to become the secondary once the cable is reattached (since the secondary is now the primary).
With the built-in replication, it's a bit difficult to turn primary to a slave (I'm not aware of a way/tool to do that and I suspect it's not possible, but maybe I'm wrong). With slaves this is possible, i.e. you may promote one slave to primary and switch the other one to follow it (instead of the old primary).
Often the primary/secondary are in the same general location and network because it is more likely that one will go down due to hardware problems than because of natural disasters requiring a remote backup server. In these cases sync issues are not an issue and if they are, then the system is not adequate to your needs. I agree a DBA should investigate if for some reason a remote slave (placed remote in case of environmental disaster) wants to try to take over, but not for the very much more common local primary/secondary set up.
I don't think there's a big difference between local and remote replication, although keeping a slave at a different location makes certain kind of problems more likely (I've seen cables nicely cut with a digger, data centers that went completely down because of failed ups, we had floods here a few years ago, etc.) but even with a single site you need two separate network paths (what if a switch fails?). And it's very easy to end with two machines thinking they're primary. That's a classical network partitioning problem and it may do a lot of harm ...
But sure - there are cases where automatic failover is probably the right thing to do, no doubt about that. I'm just saying it's very difficult to implement that in a sufficiently generic way - that's one of the nice things on PostgreSQL that you may configure it to your needs. The "unix mentality" of the development means there won't be any such "complete HA solution" anytime soon, but I do expect external packages to do the same thing (I've already mentioned repmgr) and some might move to contrib eventually.
Aaaaarghhhhh, submitted before noticing the whole post is a single paragraph. So once again in a bit more legible form:
Yes, the HA stuff is not as nicely wrapped as in other databases and may require a bit of work (e.g. to write a script). There are two main reasons for that - first, the replication stuff is about 1 year old and the developers prefer to build just very basic functionality first and see how that works. Second, the developers tend to have "unix mentality" i.e. they prefer to build tools that are easy to extend with other tools (as with "|" in the unix shell). So there's just a bare replication stuff, they're improving it where needed (e.g. the monitoring is going to be much better in 9.1, synchronous replication was added etc.), and some of the stuff has to be implemented in external tools (e.g. the management utilities - repmgr looks really promising).
I personally don't see the need to write a script as a major obstacle, for me it's a big advantage. I work in this area for a few years and I'm really sick of those nice GUI management tools, because with a reasonably complex environment you'll have to log into multiple such tools, click a few buttons and so on. That's manual work, it's takes time and it's error prone. A simple script is much more reliable for us and it's really easy to integrate into other scripts.
And the automatic failover - I really don't like fully automatic jobs in most cases. I've seen so many cases when this backfired I prefer a solution that gives the admin an opportunity to verify failover really is the right thing to do. For example when replicating to different location, there're so many possible reasons why the master might be unavailable and the slave might belive it's time to become master ... But even when such automatic failover should happen, it's usually pretty simple to script that does it.
Not sure what you find tedious on the security ... For me it's pretty straigtforward, and actually you don't need to modify the config file when creating a new user in most cases. I usually set it once at the beginning, stating something like 'remote users need to provide password, local users can access without password' or something like that. And then you don't need to touch it for a year, then someone wants to add kerberos for some users or something like that - a simple edit.
I'm a really confused by the rest of your post, because schemas are threated almost exactly as you describe. It seems you've missed the 'search_path' that allows you to define a list of schemas - the objects are searched in those schemas and the first matching object is returned. So you don't have to prepend the object name with a schema name, just set the search_path properly.
BTW I'm not aware of a database that searches for the object in all schemas the user has permissions on - e.g. Oracle searches in the "current schema" only and you have to create synonyms to access objects in other schemas this way. Try to create two users, create a table in one of them, grant privileges on the table to the other user and let the other user select data from it (without referencing the schema name) - doesn't work. You have to create a synonym. You can create a 'invoke rights' procedure, but even that one resolves the objects this way. (With search_path this can be done quite easily, just put there more schema names.)
Actually this makes the application a bit fragile - say there are three applications in separate schemas A, B and C. Application A uses table X in schema C without schema name. Then the application C is extended with a table X - ooops, the application suddenly does not work, because it references the wrong table.
Yes, the HA stuff is not as nicely wrapped as in other databases and may require a bit of work (e.g. to write a script). There are two main reasons for that - first, the replication stuff is about 1 year old and the developers prefer to build just very basic functionality first and see how that works. Second, the developers tend to have "unix mentality" i.e. they prefer to build tools that are easy to extend with other tools (as with "|" in the unix shell). So there's just a bare replication stuff, they're improving it where needed (e.g. the monitoring is going to be much better in 9.1, synchronous replication was added etc.), and some of the stuff has to be implemented in external tools (e.g. the management utilities - repmgr looks really promising). I personally don't see the need to write a script as a major obstacle, for me it's a big advantage. I work in this area for a few years and I'm really sick of those nice GUI management tools, because with a reasonably complex environment you'll have to log into multiple such tools, click a few buttons and so on. That's manual work, it's takes time and it's error prone. A simple script is much more reliable for us and it's really easy to integrate into other scripts. And the automatic failover - I really don't like fully automatic jobs in most cases. I've seen so many cases when this backfired I prefer a solution that gives the admin an opportunity to verify failover really is the right thing to do. For example when replicating to different location, there're so many possible reasons why the master might be unavailable and the slave might belive it's time to become master ... But even when such automatic failover should happen, it's usually pretty simple to script that does it.
Not sure what you find tedious on the security ... For me it's pretty straigtforward, and actually you don't need to modify the config file when creating a new user in most cases. I usually set it once at the beginning, stating something like 'remote users need to provide password, local users can access without password' or something like that. And then you don't need to touch it for a year, then someone wants to add kerberos for some users - a simple edit.
I'm a really confused by the rest of your post, because schemas are threated almost exactly as you describe. It seems you've missed the 'search_path' that allows you to define a list of schemas - the objects are searched in those schemas and the first matching object is returned. So you don't have to prepend the object name with a schema name, just set the search_path properly.
BTW I'm not aware of a database that searches for the object in all schemas the user has permissions on - e.g. Oracle searches in the "current schema" only and you have to create synonyms to access objects in other schemas this way. Try to create two users, create a table in one of them, grant privileges on the table to the other user and let the other user select data from it (without referencing the schema name) - doesn't work. You have to create a synonym. You can create a 'invoke rights' procedure, but even that one resolves the objects this way.
Actually this makes the application a bit fragile - say there are three applications in separate schemas A, B and C. Application A uses table X in schema C without schema name. Then the application C is extended with a table X - ooops, the application suddenly does not work, because it references the wrong table.
100% true
The ACID does not imply that the database has to support foreign keys. A RDBMS may be ACID compliant and not to support referential integrity. It just says that if it does, it must enforce it properly. I'm not saying I like RDBMS that lack FKs. I was just a bit afraid you believe "relational = allows to create relations between tables (FK)" - I've heard that nonsense too often.
MySQL does support FKs if you're using InnoDB engine. And how's that related to duplicate items? That's a UNIQUE constraint ...
I prefer databases that support FK, but I don't see why a RDBMS has to support FKs.