Какой запрос будет работать для этого отношения подтипа/супертипа?

Question

Вот ситуация. У меня есть 3 таблицы, один типа супер, и два подвида, с соотношением между подтипами:

|----------------| |-------------------| |-------------------| 
|  Post  | |  Top_Level  | |  Comment  | 
|----------------| |-------------------| |-------------------| 
| PK | ID  | | PK, FK | Post_ID | | PK, FK | Post_ID | 
| | DATE  | |  | Title | |  FK | TopLv_ID | 
| | Text  | |-------------------| |-------------------| 
|----------------|             

Каждой запись, либо комментарий или top_lev, является уникальным, но сущности разделяют некоторые атрибуты. Таким образом, комментарий и top_lev являются подтипами сообщения. Это одна порция. Кроме того, комментарии связаны с сообщением top_lev. Эта диаграмма ER иллюстрирует это: http://img11.imageshack.us/img11/9327/sampleer.png

Что я ищу - это список сообщений Top_Level, упорядоченных по активности на этом сообщении top_level, либо создание сообщения top_level, либо комментарий к этому сообщению.

Например, предположим, что мы имеем следующие данные:

|------------------------| |------------------| |--------------------| 
|  Post    | |  Top_Level | |  Comment  | 
|------------------------| |------------------| |--------------------| 
| ID | DATE | Text | | Post_ID | Title | | Post_ID |TopLv_ID | 
|----|------------|------| |----------|-------| |----------|---------| 
| 1 | 13/03/2008 | shy | |  1 | XYZ | |  2 | 1 | 
| 2 | 14/03/2008 | mrj | |  3 | ABC | |  4 | 1 | 
| 3 | 15/03/2008 | quw | |  7 | NMO | |  5 | 3 | 
| 4 | 16/03/2008 | ksi | |------------------| |  6 | 1 | 
| 5 | 17/03/2008 | kso |       |--------------------| 
| 6 | 18/03/2008 | aoo |        
| 7 | 19/03/2008 | all |        
|------------------------|  

|--------------------------------| 
|   RESULT    | 
|--------------------------------| 
| ID | DATE | Title | Text | 
|----|------------|-------|------| 
| 7 | 19/03/2008 | 123 | all | 
| 1 | 13/03/2008 | ABC | shy | 
| 3 | 15/03/2008 | XYZ | quw | 
|--------------------------------| 

это может быть сделано с помощью одного оператора выбора? Если да, то как?

Answer 1

Я попробовал этот запрос, и это дает выход вы описываете:

SELECT pt.id, pt.`date`, t.title, pt.`text` 
FROM Top_Level t INNER JOIN Post pt ON (t.post_id = pt.id) 
LEFT OUTER JOIN (Comment c INNER JOIN Post pc ON (c.post_id = pc.id)) 
    ON (c.toplv_id = t.post_id) 
GROUP BY pt.id 
ORDER BY MAX(GREATEST(pt.`date`, pc.`date`)) ASC; 

Выход:

+----+------------+-------+------+ 
| id | date  | title | text | 
+----+------------+-------+------+ 
| 7 | 2008-03-19 | NMO | all | 
| 1 | 2008-03-13 | XYZ | shy | 
| 3 | 2008-03-15 | ABC | quw | 
+----+------------+-------+------+ 

Answer 2

Это должно быть возможно, если «дата последнего вхождения» представлена ​​в столбце Sub1 и Sub2. Обратите внимание, что код, который я перечисляю, в основном псевдокод ... вам нужно заполнить пробелы в соответствии с вашим вкусом dbms.

ограничить результат набора только столбцов в SUPER и SUB1 (без простофили):

SELECT DISTINCT sub1.*, super.* 

(очевидно, вы должны стараться избегать SELECT * ... выбрать столбцы, которые вам действительно нужно)

You ЕКА будет выглядеть примерно так:

FROM super INNER JOIN sub1 ON super_id 
    LEFT JOIN sub2 ON super_id AND sub1_id 

И ORDER BY будет использовать функцию COALESCE (если СУБД поддерживает его), чтобы выяснить, какой столбец для сортировки (COALES CE выбирает первое ненулевое значение в списке аргументов):

ORDER BY COALESCE(sub2.dateColumn, sub1.dateColumn) 

В качестве альтернативы, если у вас нет COALESCE доступны, но у вас есть функция ISNULL доступен, вы можете цепи ISNULLs:

ORDER BY ISNULL(firstDateColumn, ISNULL(secondDateColumn, thirdDateColumn)) 

Answer 3

Возможно, вы, возможно, непреднамеренно полностью запутали ваш вопрос, что очень затрудняет понимание и ответ (по крайней мере, для тех из нас, у кого небольшие мозги.) Не могли бы вы скорректировать его с помощью разумных имен таблиц и полей и более полного описания индексов?

---

EDIT:

Вы, возможно, описывая ситуацию, когда продукты продаются, а также иногда одни и те же продукты могут быть включены в качестве компонентов в других продуктах рекурсивно? Если это так, есть более традиционные успешные способы моделирования ситуации.

Answer 4

Вы не предлагали и не намекали на то, что схема может быть переработана, поэтому, возможно, я задаю этот вопрос не наилучшим образом использующим ваше время и мое, но: ваши таблицы имеют, которые будут разработаны для этого путь? Используется ли это приложение уже в производстве?

Что вызвало эту мысль в моей голове было ваше заявление:

Все события происходят на сегодняшний день, но редактирование должно быть связано с событием оригинальные создания

Я подозреваю, что это обоснование наличия суб-2 включает FK в sub1. Но это кажется мне денормализацией (в реляционных терминах) или нарушением принципа DRY (в Agile-терминах). В любом случае это может сделать вашу жизнь более сложной, чем она должна быть.

Мой совет (стоит того, за что вы платите за него) должен был удалить FK в sub1. Вместо этого вы можете: 1) включить SELECT в событие создания страницы, как часть запроса, или 2) перенести дату создания в таблицу страниц. (Какой из этих вариантов вы используете, зависит от того, какая дополнительная сложность существует в схеме, я обычно предпочитаю # 1 над # 2.)

Я думаю, что это упростит ваши обновления, а также ваши запросы. Ваш пробег может отличаться.