I suspect that using unordered sets as the foundation for databases might have been a mistake, and ordered lists with allowed repetition would've made a better model, if only because they can model tables and query results equally well (ORDER BY, SELECT without DISTINCT). Is there a good reason why this road was not taken?
In most actual implementations of relational DBs there's nothing to disallow repetition in a table - you just don't specify a primary key (or preferably have a unique primary key that's just an ignored surrogate).
The difficulty with caring about ordering in the relational model is that suddenly you're imposing a lot more constraints: when you're joining two tables, whose order 'wins'? If you say (for example) that left side wins, you then need to keep track of that order through your query.
Comments
I suspect that using unordered sets as the foundation for databases might have been a mistake, and ordered lists with allowed repetition would've made a better model, if only because they can model tables and query results equally well (ORDER BY, SELECT without DISTINCT). Is there a good reason why this road was not taken?
In most actual implementations of relational DBs there's nothing to disallow repetition in a table - you just don't specify a primary key (or preferably have a unique primary key that's just an ignored surrogate).
The difficulty with caring about ordering in the relational model is that suddenly you're imposing a lot more constraints: when you're joining two tables, whose order 'wins'? If you say (for example) that left side wins, you then need to keep track of that order through your query.
Would you want bag semantics for things like union and intersection then?
Yes, that sounds reasonable. I don't know very much about the practical uses of union and intersection in SQL, though.