Re^2: Re-indexing a SQL resultset by id

in reply to Re: Re-indexing a SQL resultset by id
in thread Re-indexing a SQL resultset by id

It seems to me that your database design (or the name of the 'id' column) is broken if you have non-unique ID's.

FALSE:

CREATE TABLE students
  id PRIMARY KEY SERIAL
  firstname TEXT
  lastname TEXT
;
CREATE TABLE classes
  id PRIMARY KEY SERIAL
  name text
;
CREATE TABLE student_classes
  studentid  INT
  classid INT
;
[download]

and now:

SELECT  * FROM student_classes;
[download]

Will you get several instances of each id? Yes? Is the database design un-normalized? No. Conclusion. There are reasonable queries leading to multiple instances of certain fields by which one might want to collate results. In this case, I might want a hash keyed by student id and an array ref of all results with that student id. Call it "collation".

The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.

-- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"

Comment on Re^2: Re-indexing a SQL resultset by id Select or Download Code

Replies are listed 'Best First'.
Re^3: Re-indexing a SQL resultset by id by Juerd (Abbot) on Jul 09, 2011 at 23:42 UTC
SELECT * FROM student_classes; Will you get several instances of each id? Yes? Yes, but these fields are not called 'id'; here, it's just a suffix. A join, however, could result in multiple rows of the result set with the same id, even in a nice database design, so I do retract my observation about the database perhaps not being well-designed. Juerd	[reply]

In Section Seekers of Perl Wisdom