A developer I work with insists on maintaining a foreign key constraint in a database (MySQL) where the tables containing the related data are read only. How do I politely tell him this is unnecessary?
Related
I wonder how db schema design would look, because at first glance I need bunch sql relation features, that are not available out of box in QuestDB.
No, QuestDB does not support PK, FK and any other constraints yet.
Schema can be same as other relational databases, except the PK values have to be generated by the application. QuestDB will not enforce uniqueness of values in a table column and uniqueness has to come from inserting application.
I am working on a Django project with a database in PostgreSQL. During my schema design, I have noticed that one table is referencing many foreign keys from other tables. Just curious that how many foreign keys can be referenced from/to one table? I also searched and found that the SQL server 2014 can reference up to253 foreign keys.
I don't think there is a hard limit. I just created a table with 10001 foreign key constraints.
Of course that doesn't mean that it is sane to define that many foreign keys, and performance will suffer considerably.
I'm trying to setup a new server with foreign tables (using postgres_fdw) that weren't foreign tables previously, and I have some OneToOneFields pointing to these tables. This doesn't work out of the box - OneToOneFields use foreign keys, and postgres_fdw does not support foreign keys for foreign tables.
The foreign tables are in a read-only database on the same server.
Is there an easy way to get this working?
After a little more research, I think the answer is 'don't do that'. Handling foreign keys for foreign tables isn't implemented, and any solution that tried to bridge that gap would have serious performance and/or consistency issues.
pglogical looks like a better solution - instead of pulling the data in through postgres_fdw, replicate the tables into the new database so they're local. There are other projects for replicating just specific tables, but pglogical is included with PostgreSQL 10.
I have an existing database with several rows that violate a foreign key constraint. How do I script this situation in a new database?
I believe some databases can create constraints that do not validate pre-existing data but cannot find this option in Sybase 12.
Sybase ASE 12.5
Adding a constraint doesn't validate against existing data.
So drop it, bob some garbage in and put it back...
I have a requirement according to which I have to create a central Login system.We have 2 things Corporate and Brand each represented by tables "Corporate" and "Brand".
When a corporate gets registered,corporateID is given,When a user under that corporate gets registered there is a table corporateuser in which corporateID is a foreign key and CorporateUserID is a primary key.Similarly in the case of a brand.
So we have CorporateUserId and BrandUserID.
Now i have a table called RegisteredUsers in which i want to have corporate as well as brand users.UserID is a primary key in this table which is a foreign key to both corporateuser as well as Branduser.
now when i enter a corporateuser,I do an entry to corporateuser as well as RegisteredUsers.When i enter CorporateUserID in userID for RegisteredUsers.It gives foreign key violation error.
I fully understand this error.How can i achieve this.This requirement is very rigid.Please tell a workaround
What you're trying to do is not totally clear, but it seems that you want the primary key of all three user tables to be the same. This is not a strict foreign key relationship, but it seems reasonable in your application.
You need to assign the userID in RegisteredUsers first, and use that key when you create your Corporate User or Brand User. Then the user id's will be unique across the whole system.
If that's not what you want, edit your entry with the table layouts to make the problem clearer.
If you are trying to insert records into tables with relational conatraints, you will need do all inserts under one SQL Transaction.