I have a simple 2 CentOS servers configurations using both postgres-9.4 to simulate the FDW scenario in Postgres-9.4.
I used fdw to link a simple table with a another database on another server, reading worked perfectly from both ends,the issue was with the serial primary key, it was not in sync; in other words, If I inserted from the original table, after I inserted from the foreign table, it doesn't sync the count. and vise versa.
Based on the comment I got from Nick Barnes, yes I do need to keep up the counter on both sides in sync, so I made a Function that every time Queries the Actual Database for the latest index, so that is always inserts to the correct record.
I am still not sure if this is going to survive, but I'll make it work production really soon.
I blogged about it here with a table example.
I had the same problem, and tried it like Negma suggested in his blog. This solution only works in case you insert only one row. In case you insert more rows in the same transaction, select max(id) will always return the same id and you will get not unique ids.
I have solved this by changing the type of the id from serial/integer to uuid. Then you can do the same as Negma suggested but with gen_random_uuid() from the pgcrypto EXTENSION.
So at the foreign server I did:
ALTER TABLE tablename ALTER COLUMN columnname SET DEFAULT gen_random_uuid();
And the same for the foreign table.
Related
I went for an interview today where they give me technical test on sql. One of them was how to delete duplicate records without a primary key.
For one I can't imagine a table without a primary key. Yes I have read the existing threads on this. Say this happened and needed to be fixed Now. Couldn't I just add to the end of the table a automatically incrementing id then use that to delete the duplicate record?
Can anyone think of a reason why that won't work? I tried it on a simple database I created and I can't see any problems
You've got a couple of options here.
If they don't mind you dropping the table you could SELECT DISTINCT * from the table in question and then INSERT this into a new table, DROPping the old table as you go. This obviously won't be usable in a Production database but can be useful for where someone has mucked up a routine that's populating a data warehouse for example.
Alternatively you could effectively create a temporary index by using the row number as per this answer. That answer shows you how to use the built in row_number() function in SQL server but could be replicated in other RDBMS' (not sure which but MySQL certainly) by declaring a variable called #row_num or equivalent and then using it in your SELECT statement as:
SET #row_num=0;
SELECT #row_num:=#row_num+1 AS row_num, [REMAINING COLUMNS GO HERE]
One of possible options how to do this:
select distinct rows from your table(you can achieve this using group by all columns)
insert result into new table
drop first table
alter second table to name of first one
But this is not always possible in production
im programming a app to perform CRUD to any given table in any given database (MySQL).
Im having trouble figuring the best way to deal with the Update operation.
I was thinking: 1)Find Primary Key on table & 2)Update record according to Primary Key field coincidence between both records (incoming and allready present in MySQL table).
I know that while Primary Key in every table is very suggested it is still optional, so as i said im not sure if theres a better aproach since my method would not work with a table without a Primary Key.
Thanks in advance.
The answer i found that i believe is valid is the following: For the Update action send two records to the server, the non updated one and the updated one.
The server side has to include each field of the non-updated record in the where clause of the update query with LIMIT=1 (to avoid problems with duplicated records).
I have a table with an AUTO_INCREMENT primary key. If the last row in the table is deleted, the next-inserted row will take the same ID.
Is there a way of getting MySQL to behave like t-SQL, and not reuse the ID? Then if the deleted row is erroneously referenced from something external to the database, no rows will be returned, highlighting the error.
In this case, you probably should not be using AUTO_INCREMENT indices in publicly accessible places.
Either derive a key field from other data, or use a different mechanism to create your id's. One way I've used before, although you need to be aware of the (potentially severe) performance implications, is a "keys" table to track the last-used key, and increment that.
That way, you can use any type of key you want, even non-numeric, and increment them using your own algorithm.
I have used 6-character alpha-numeric keys in the past:
CREATE TABLE `TableKeys` (
`table_name` VARCHAR(8) NOT NULL,
`last_key` VARCHAR(6) NOT NULL,
PRIMARY KEY (`table_name`)
);
SELECT * FROM `TableKeys`;
table_name | last_key
-----------+---------
users | U00003A2
articles | A000166D
products | P000009G
As of MySQL version 8, MySQL no longer re-uses AUTO_INCREMENT ID values, fixing the long-standing (opened in 2003!!) bug #199.
For more info, see this blog post by MySQL Community Manager lefred: https://lefred.be/content/bye-bye-bug-199/
That's not the way our MySQL databases work, when a record is deleted the next inserted has the next number, not the one that was deleted.
As I understand it, there is no way of doing this. You might consider working around it by adding a deleted flag, and then setting the deleted flag instead of removing the row.
The "right" answer is that once a row is deleted, you shouldn't be referencing it. You can add foreign keys to make sure that the db will not allow rows to be deleted that are referenced elsewhere in the db.
Mysql manual says:
In this case (when the AUTO_INCREMENT column is part of a multiple-column index), AUTO_INCREMENT values are reused if you delete the row with the biggest AUTO_INCREMENT value in any group. This happens even for MyISAM tables, for which AUTO_INCREMENT values normally are not reused.
It seems there is such a behavior possible for the engines, other than MyISAM
Earlier today I asked this question which arose from A- My poor planning and B- My complete disregard for the practice of normalizing databases. I spent the last 8 hours reading about normalizing databases and the finer points of JOIN and worked my way through the SQLZoo.com tutorials.
I am enlightened. I understand the purpose of database normalization and how it can suit me. Except that I'm not entirely sure how to execute that vision from a procedural standpoint.
Here's my old vision: 1 table called "files" that held, let's say, a file id and a file url and appropos grade levels for that file.
New vision!: 1 table for "files", 1 table for "grades", and a junction table to mediate.
But that's not my problem. This is a really basic Q that I'm sure has an obvious answer- When I create a record in "files", it gets assigned the incremented primary key automatically (file_id). However, from now on I'm going to need to write that file_id to the other tables as well. Because I don't assign that id manually, how do I know what it is?
If I upload text.doc and it gets file_id 123, how do I know it got 123 in order to write it to "grades" and the junction table? I can't do a max(file_id) because if you have concurrent users, you might nab a different id. I just don't know how to get the file_id value without having manually assigned it.
You may want to use LAST_INSERT_ID() as in the following example:
START TRANSACTION;
INSERT INTO files (file_id, url) VALUES (NULL, 'text.doc');
INSERT INTO grades (file_id, grade) VALUES (LAST_INSERT_ID(), 'some-grade');
COMMIT;
The transaction ensures that the operation remains atomic: This guarantees that either both inserts complete successfully or none at all. This is optional, but it is recommended in order to maintain the integrity of the data.
For LAST_INSERT_ID(), the most
recently generated ID is maintained in
the server on a per-connection basis.
It is not changed by another client.
It is not even changed if you update
another AUTO_INCREMENT column with a
nonmagic value (that is, a value that
is not NULL and not 0).
Using
LAST_INSERT_ID() and AUTO_INCREMENT
columns simultaneously from multiple
clients is perfectly valid. Each
client will receive the last inserted
ID for the last statement that client
executed.
Source and further reading:
MySQL Reference: How to Get the Unique ID for the Last Inserted Row
MySQL Reference: START TRANSACTION, COMMIT, and ROLLBACK Syntax
In PHP to get the automatically generated ID of a MySQL record, use mysqli->insert_id property of your mysqli object.
How are you going to find the entry tomorrow, after your program has forgotten the value of last_insert_id()?
Using a surrogate key is fine, but your table still represents an entity, and you should be able to answer the question: what measurable properties define this particular entity? The set of these properties are the natural key of your table, and even if you use surrogate keys, such a natural key should always exist and you should use it to retrieve information from the table. Use the surrogate key to enforce referential integrity, for indexing purpuses and to make joins easier on the eye. But don't let them escape from the database
I'm a little rusty with my triggers and what not and am trying to figure out this problem for a class:
In a database TEST, tables do not have the option of the IDENTITY feature. In other words, when we insert a row into the table “Users”, we would like the primary key “UserID” to auto-increment. Please suggest a workaround to implement this feature without such a built-in functionality.
(Hint: You may still use functions, stored procedures, sequences, triggers, etc)
Use an Int column for the table Primary Key called ID.
You can then use an instead of Insert Trigger, to populate/calculate the value to be inserted for ID.
The trigger will determine what the maximum existing ID is for the table in question (using select MAX ID from TableA) and then increment it by 1 for each record to be inserted.
If there are no records in the table then the ID value is 1.
You use a sequence, and it's very common with Oracle, which does not (or did not once, it may have changed) have identity columns. Since this is homework I'll let you figure out the rest from here.