Federico Granata wrote:
>> Your example doesn't counter my suggestion at all, which is to use the data
>> only and not a special rowid. So you put 2 identical rows in a table.
>> Since rows in a table are unordered, there isn't even an ordinal position
>> to distinguish the 2 occurrences of that same row. Since they are
>> identical, they are redundant, and so they are equivalent to just 1 such
>> row. So updating both copies is perfectly fine. Though better yet is to
>> not store a second copy in the first place.
>>
> LOL
> English isn't my first language but I think you are joking ...
>
> If I want to make a table with a list of people (name and age) I can have
> two or more row with the same name and age and they aren't redundant and the
> implicit rowid is different.
The normal proper way to do what you said is to declare a table like this:
CREATE TABLE person (
person_id INT PRIMARY KEY,
name TEXT,
birthdate DATE
)
In my example, you are using only the normal data, which is the 3 columns
specified, and you are not referring to a column you didn't declare
("rowid" or whatever), but by a column you did declare, "person_id".
By contrast, defining a table like this is inferior:
CREATE TABLE person (
name TEXT,
birthdate DATE
)
In that example, the rowid would be generated and you can't use something
externally meaningful (such as SSN) to distinguish one Joe from another.
My point still stands. Or my other point of adding a LIMIT clause to
UPDATE also stands if you want to create tables the second way.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
