fenway

"multiple rows as one row" ==> either means you want group-concat or you want joins.

I'm not sure I understand why you have a group by with so many fields in the select list. Is is faster if you drop the group by / order by?

Sounds like you're working with a non-normalized table design.

Don't worry about one-to-one vs one-to-many at this stage... it doesn't matter for the constraints.

Which one? Link to it.

That's sounding very much like a description of XML.

Same goes for H1 -- you don't need any CSS to get to do display differently than non-H1 text. Regardless, I've been building web pages since 1996, when CSS didn't even exist. And _before_ CSS came along, everyone was happily creating "presentation markup" with HTML alone. BTW, the last line of the intro wikipedia article on HTML reads: So even the W3C will concede that HTML allows for "explicit presentation markup". CSS changes nothing -- it just gives you yet another way to affect the presentation. The fact that everyone really wants to ignore that HTML still -- and will forever -- let you specify when your text is bold is just silly. I'm not suggesting that it isn't better to move the presentation layer to CSS -- just that HTML has such elements.

Just because the "standards" suggest that CSS is the "presentation layer" doesn't preclude the fact that every single HTML tag represents a presentation element.

Your SQL query is behaving exactly as you asked it to. You asked your query to GROUP BY id -- so it did. That means any other non-dependent column value is meaningless. Show us some sample data.

FKs do not impose any restrictions that requires concatenating columns... please clarify.

I couldn't disagree more -- the entire purpose of the markup is to convey presentation information. That's why everyone is so upset when people use tables for non-tabular data. Just because the browser displays it better as a <table>, doesn't mean it's a "table". The fact that CSS and JavaScript can inject additional instructions that modulate the underlying HTML markup is irrelevant.

When I said "for the purposes of programming", I meant for comparison PHP to HTML.

To clarify, write a select query with a GROUP BY on the programme, then JOIN that back using a derived table to get whatever else you desire.

For the purposes of programming, I consider anything resembling a language to have syntax, not markup -- so HTML falls outside my definition. Frankly, I don't care how the "L" came about.

It acts entirely like a templating system would. Where I come from, any markup is just a glorified template. Think about it. A bold tag can be thought as representing "replace these characters with bold characters". I have built many template systems that all work on the same principle.

Says who?

What was wrong with REPLACE()? TRIM() won't find embedded hyphens.

That is the way -- and you already have everything you need.

I always considered HTML more of a template.

Sounds like a question for "one of your seniors". Anything is possible... but it's a bad idea.

First you need to get a unique list of programmes... then join this back to the table of episodes.

Yeesh... echo the actual query you produce.

I still don't see why you just can't query each column separately.

Absolutely... use DATE() or TIME(), or their respective format functions.

I don't follow... what are you trying to do?