двойная сортировка в SQL-запросе

Не могу создать правильный запрос к таблице с двумя сортировками дат

Есть таблица, надо что бы сортировалась от большей даты к меньшей, независимо от колонки.
-------------------------------- ----
| id | date1 | date2 |
-------------------------------- ----
| 1 | 2014-10-20| 2014-10-25|
| 2 | 2014-10-21| 2014-11-20|
| 3 | 2014-10-15| 0000-00-00|
| 4 | 2014-10-10| 2014-10-20|
| 5 | 2014-11-22| 0000-00-00|
| 6 | 2014-10-13| 2014-11-25|

Что надо получить:
------------------------------------
| id | date1 | date2 |
-------------------------------- ----
| 6 | 2014-10-13| 2014-11-25|
| 5 | 2014-11-22| 0000-00-00|
| 2 | 2014-10-21| 2014-11-20|
| 1 | 2014-10-20| 2014-10-25|
| 4 | 2014-10-10| 2014-10-20|
| 3 | 2014-10-15| 0000-00-00|



Со стандартной сортировкой отлично знаком и ORDER BY date1 DESC, date2 DESC даст таблицу. Что совсем не то что надо
------------------------------------
| id | date1 | date2 |
-------------------------------- ----
| 5 | 2014-11-22| 0000-00-00|
| 2 | 2014-10-21| 2014-11-20|
| 1 | 2014-10-20| 2014-10-25|
| 3 | 2014-10-15| 0000-00-00|
| 6 | 2014-10-13| 2014-11-25|
| 4 | 2014-10-10| 2014-10-20|

Буду благодарен Вашей помощи знатоки

Я не понял, по какому признаку получился образец желаемой сортировки, так что играйтесь откуда-то отсюда:

-----
PostgreSQL DBA

Все, задача решена. Оказалось все проще))
Решение:

соображения понятны
нужна дата сортировки
это ясно
не об этом
если таблица не маленькая или хочет в будущем расти тут явно лучше добавить дополнительное индексное поле(иначе каждая выборка это полный перебор всей таблицы в экспоненте)
в котором будет хранится бОльшая из дат
и тогда сортировка по одному проиндексированному полю
быстро и не сердито
(Добавление)
ну а раз пошла такая пьянка то из бОльшей даты формируешь целое число путем удаления разделителей и индексируешь по целочисленному полю
таблица будет летать))

Ну да таблица большая, 37000 пока, а колонок так вообще более 50и. Но одна из дат регулярно меняется, а другая дата создания записи. Тоже думал создать третью дату которая за все это и будет отвечать. Но структура и организация ЦРМки "кустарная" поэтому при добавлении третьей даты я замучаюсь всю систему подгонять под нее

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

Блин, точно. Тригеры всему решения. Большое спасибо