I learned that there is no concept of order in terms of tuples (e.g. rows) in a table but according to wikipedia "a tuple is an ordered list of elements". Does that mean that attributes do have an order? If yes why would they be treated differently, couldn't one add another column to a table (which is why the tuples don't have order)?
"In this notation, attribute–value pairs may appear in any order." does this mean attributes have no order?
There are 2 kinds of tuples, so to speak. There is "pure mathematics", and there indeed tuples are typically defined as "ordered lists of values". Thus, in mathematical theories, it makes sense to speak of "the first value in a tuple" and such. This may be the sense or the context that your Wikipedia article is referring to.
The Haskell language supports this kind of tuple and, e.g., it also has a fst() operator to extract the "first" value out of such a tuple.
Codd realized, however, that this would be extremely impractical when applying this mathematical concept of tuples-as-ordered-lists to the field of data management. In data management, he wanted addressability of the values by attribute name, rather than by ordinal position. Indeed, imagine the devastating consequences if "the second attribute out of five" is removed from a table, and now all the programs that address "the third" and "the fourth" attribute of that same table now have to be inventarised and adapted.
So in the relational model, tuples are sets-of-named-values instead, and consequently, in the kind of tuples that play a role in the relational model of data, there is indeed not any concept of ordering of the values.
And then as indicated in that other response, there is SQL and its blasphemous deviations from relational theory. In SQL, the ordering of attributes in tuples and headings is quite meaningful, and the consequences are all over the place. In FK declarations, correspondance of the respective referring and referred attributes is by ordinal position, not by name. Other cases are with UNIONs and EXCEPTs. Take a table T, columns X and Y the same type.
SELECT X,Y FROM T UNION SELECT Y,X FROM T
is not invalid per se, but the standard prescribes that the column names in the result are system-defined (!). Implementations that "do the sensible thing" and deviate from this, producing a table with columns named X and Y, respectively, then face their users with the consequence that the former expression is not identical to
SELECT Y,X FROM T UNION SELECT X,Y FROM T
(because the column ordering X,Y is another ordering than Y,X and thence the headings are unequal, and consequently the tables are unequal.)
SELECT X,Y FROM T EXCEPT SELECT Y,X FROM T
gives results that will leave many novice SQL users scratching their heads for quite a while.
The operations of the relational database model as it is normally understood and used certainly do not depend on the order of attributes in a relation. The attributes of a relation variable can always be identified by name rather than position. However, the notation used in relational database theory doesn't always specify attribute names (or attribute types) and sometimes does imply ordered attributes. This is primarily a matter of written notation rather than the structure or behaviour of the relational model. There's some more discussion of these different "named" and "ordered" perspectives in the following reference. http://webdam.inria.fr/Alice/pdfs/Chapter-3.pdf
E.F.Codd's earliest papers on the relational model actually proposed a relational system supporting both ordered and unordered versions of relations simultaneously. That idea seems to have been forgotten or ignored ever since, even by Codd himself. It doesn't form part of modern relational database theory.
Unfortunately, SQL definitely does have the concept of column order. It is an essential part of SQL syntax and semantics and it's something that every SQL DBMS supports in order to comply with the ISO SQL standard. SQL is not relational and this is just one of the ways in which it differs from the relational model. The awkward differences between the SQL model and the relational one cause a certain amount of confusion for students of the relational model who also use SQL.
Mathematical and philosophical arguments aside, look at it practically with some real-world examples.
Suppose you write this SQL:
INSERT INTO mytable
SELECT
a1, a2, ... a99
FROM anothertable;
Suppose this works just fine, because the order in which the SELECT returns the 99 columns is the same at each run, and matches the order of the colums needed for mytable.
But suppose that I am given the task to review this code, written by my colleague. How do you review if the columns are in the correct order? I will have to do some digging in other parts of the system, where mytable is constructed, to check if the columns are in the correct order. So the correctness of this SQL depends on other code, perhaps in other code in far and obscure places.
Case 2: suppose, the hypothetical list of columns looks like this:
...
a63,
apt_inspecties.buurtcode_dominant,
apt_inspecties.buurtnaam_dominant,
--
apt_inspecties.buurtnaam,
apt_inspecties.buurtcode,
--
apt_inspecties.wijknaam_dominant,
apt_inspecties.wijkcode_dominant,
--
apt_inspecties.wijknaam,
apt_inspecties.wijkcode,
--
apt_inspecties.stadsdeelnaam_dominant,
apt_inspecties.stadsdeelcode_dominant,
--
apt_inspecties.stadsdeelnaam,
apt_inspecties.stadsdeelcode,
--
apt_inspecties.ggwnaam_dominant,
apt_inspecties.ggwcode_dominant,
--
apt_inspecties.ggwnaam,
apt_inspecties.ggwcode,
a80,
a81,
...
Then there will be someone sometime who wants to reorder the first naam/code lines to get the list in a more systematic order with 8 times naam then code order, like this:
a63,
apt_inspecties.buurtnaam_dominant,
apt_inspecties.buurtcode_dominant,
But this would not be possible, unless, in other code the order of attributes is also changed. But then there is the risk that again other code that also relies on the implicit order of attributes goes wrong.
The obvious solution is to ALWAYS practice defensive coding like:
INSERT INTO mytable(a1, ... a99)
SELECT a1...a99
FROM anothertable;
Or, to assume that you cannot rely on implicit constant order of attributes.
Case 3:
Suppose mytable gets lost and needs to be recreated, for example from backup data. And suppose that it is recreated with another ordering of attributes. Or, someone does an ALTER TABLE to remove one attribute, and later another ALTER TABLE to add this attribute back in, thereby changing the order of attributes.
I believe that everybody would agree that the resulting table is the same as the original table. You would look at the data and see that the relation between a1 and a2 (etc) is the same. Same number of rows.
If you do any query like
SELECT ai, aj FROM mytable;
the output will be what you would expect from the original table.
However, the above SQL would fail, because it relies on one particular implicit ordering of attributes.
Conclusion:
For a relational database, such as Oracle, Postgresql, MySql, whatever, the ordering of rows and of attributes has no meaning. Name the attributes in your SQL to force the desired order of attributes, and use an ORDER BY clause to force the ordering of rows.
This is related to strong typing in programming languages. Not everybody likes that, and some modern languages do not have strong typing, like javascript, python. However, for writing larger code, strong typing is very important, and then typescript seems to replace (supplement) javascript.
