In SQL do updates accumulate or overwrite?

[scripting]

Suppose I have table with three fields -- id, weight, when
	we're keeping track of people and their weight.
	id identifies a person
	weight is their weight
	when is when the reading took place
I enter the weight every week
	when I do that, does that create a new row in the table, or does it replace the existing row?
I have a feeling it has to do with keys
	I don't even remember if SQL databases have keys!
	So this is a crucial question.
	If they do have keys, I'd make _id_ the key.
	Note I _want_ it to overwrite. I don't care what the person's weight was last week or year. 

[jonsagara]

Yes, updates overwrite.

Assuming id is the primary key in the Weights table, the very first time this person weighs him/herself, you'd

INSERT INTO Weights(id, weight, when) VALUES (1, 150.0, 'measurement-date-here')

To overwrite on subsequent measurements for the same person, you'd

UPDATE Weights SET weight = 150.5, when = 'new-date-here' WHERE id = 1

[jswright61]

OK - I'm going to try and keep this simple.

Overwrite or Update depends upon whether you do an UPDATE (overwrite) or INSERT (new row)

That answers your question, but there is more implied - see below

[sivabalans]

UPDATE table weights set weight = "some_weight" where id = "some_id" - Always updates the row.
INSERT table weights (id, weight, when) - Always inserts a row.
So when updating the weight of a person by supplying an existing ID, it should update the row.
If you try to update the weight of a person by supplying a non-existent ID, it should throw a SQL error.
If you try to insert the weight of a person with a non-existent ID, it should insert a new row
If you try to insert a weight of person with an existing ID, and if that column has a Unique index(which it should), it should throw a SQL error.

[jswright61]

You probably want a 'person' table, with an id which is its primary key.

Then a weights table with an id as primary key, and a person_id as a foreign key.

[scripting]

So if I'm setting weight data for a person, first I have to check if I already have weight data for that person, and do an update. If I don't have the data, do an insert.

…

On Wed, Oct 11, 2017 at 12:43 PM, sivabalans ***@***.***> wrote: UPDATE table weights set weight = "some_weight" where id = "some_id" - Always updates the row. INSERT table weights (id, weight, when) - Always inserts a row. So when updating the weight of a person by supplying an existing ID, it should update the row. If you try to update the weight of a person by supplying a non-existent ID, it should throw a SQL error. If you try to insert the weight of a person with a non-existent ID, it should insert a new row If you try to insert a weight of person with an existing ID, and if that column has a Unique index(which it should), it should throw a SQL error. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABm9O4cOONiWIKCb6ywilaiPAHiXSUe1ks5srPAfgaJpZM4P1vCu> .

[sivabalans]

Yes, that is correct. On Wed, Oct 11, 2017 at 9:53 AM, Dave Winer <notifications@github.com> wrote:

…

So if I'm setting weight data for a person, first I have to check if I already have weight data for that person, and do an update. If I don't have the data, do an insert. On Wed, Oct 11, 2017 at 12:43 PM, sivabalans ***@***.***> wrote: > UPDATE table weights set weight = "some_weight" where id = "some_id" - > Always updates the row. > INSERT table weights (id, weight, when) - Always inserts a row. > So when updating the weight of a person by supplying an existing ID, it > should update the row. > If you try to update the weight of a person by supplying a non-existent > ID, it should throw a SQL error. > If you try to insert the weight of a person with a non-existent ID, it > should insert a new row > If you try to insert a weight of person with an existing ID, and if that > column has a Unique index(which it should), it should throw a SQL error. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#36# issuecomment-335872254>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ ABm9O4cOONiWIKCb6ywilaiPAHiXSUe1ks5srPAfgaJpZM4P1vCu> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ-CitgiryjnMLHfqBm4-7WHDC-6X9Urks5srPKIgaJpZM4P1vCu> .

-- http://www.twitter.com/sivabalans

[facej]

Depending on your database. In Postgres you might use "UPSERT". In MySQL you might use "INSERT ... ON DUPLICATE KEY UPDATE"

[jswright61]

Or you can use replace instead of insert or update
Check out the replace syntax, https://dev.mysql.com/doc/refman/5.5/en/replace.html

Replace does an insert if the row with the primary key does not exist, but it deletes the old row if the key existed and then inserts the new row - saves a database trip.

You end up with a table that stores the current weight for each person, but no history.

[jswright61]

If you want history for weight, you might use a structure like this:

CREATE TABLE people (
id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
name varchar(100) DEFAULT NULL,
dob date DEFAULT NULL,
created_at datetime DEFAULT NULL,
updated_at datetime DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=1;

CREATE TABLE weights (
id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
person_id int(10) UNSIGNED DEFAULT NULL,
weight decimal(5,2) DEFAULT NULL,
created_at datetime DEFAULT NULL,
updated_at datetime DEFAULT NULL,
PRIMARY KEY (id),
CONSTRAINT fk_person FOREIGN KEY (person_id) REFERENCES people (id),
INDEX person_id USING BTREE (person_id) comment ''
) ENGINE=InnoDB AUTO_INCREMENT=1;

[scripting]

Or you can use replace instead of insert or update

BING!

[TomLoyal]

Dave,

Not that I ever ran into this in working with SQL :) , but some programmers I know have...

Thou shalt always use a where clause when doing an update, lest all rows in the table be overwritten.
Omitting columns in your REPLACE column list will cause nulls to overwrite your existing data unless those columns do not allow nulls.

Keep calm and recover with backups :)

[scripting]

I replacing all columns so I should be good. And when the time is right I'm going to post my code for review and you all can tell me how fucked I am. ;-)

[easp]

Something to be aware of: in the case of doing a replace or update, where there could be a concurrent request reading or writing the same row, you may find yourself bumping into how the SQL database you are using handles concurrency and transaction isolation. Postgres defaults to (potentially) slow, but safe. I don't know about MySQL, but in the past, it was generally rather reckless.

[danderson3]

for reference, possibly overkill: https://begriffs.com/posts/2017-08-01-practical-guide-sql-isolation.html