В стиле SQL - 5 (сортировка)

[egorius]

Нередки случаи, когда сама постановка задачи подталкивает разработчика к процедурному решению. Вот пример из практики. В кадровый отчет по сотруднику требуется выводить тип родства, ФИО и дату рождения ближайшего родственника (например: «Отец - Эпиктетов Полуэкт Полуэктович, 01.04.1900»).

Модель данных упрощенно выглядит следующим образом. Есть

Comments

[hardsign]

SQL™, конечно. Но тухлыхъ помидоровъ® ты заслужил:

1. за varchar2(1) надо отрывать... ну, ты понял
2. за null во флагах надо отрывать всё, что осталось
3. в ranked_contacts не надо включать первый people, это соединение надо вынести за with. На больших объёмах окупится
4. а если бы ты склеил ranked_contacts сам с собой при помощи union, превратив одностороннюю связь в двухстороннюю, то преимущество декларативного подхода стмло бы подавляющим

ъ!

[egorius]

О, помидорчики!
1. Ты, видимо, предлагаешь char(1)? Странный это тип, не уверен, что имеет смысл связываться с ним ради экономии пары байтиков.
2. Полностью согласен, но, поскольку пример из жизни, то и таблица® взята такая, какая в жизни.
3. Тут не понял. Мы не посчитаем ранг без people, он ведь там используется. Вот если бы не использовался, то да.
4. См. п. 2, но пожалуй ты прав, это стоило бы сделать.

[hardsign]

1. char - прекрасный тип, если использовать его для строк действительно постоянной длины
2. а проектирование структуры™ - отдельная интересная тема
3. ты прав, да, но см. п. 2. По зрелом размышлении я бы завёл отдельные классы для отношения "мать сына", "отец дочери", "муж" и т. д., чтобы можно было однозначно инвертировать значение.

[egorius]

По п. 2 у меня опыт невелик... Тем не менее он подсказывает мне, что не стоит сильно затачивать структуру под отдельно взятую и, скорее всего, второстепенную задачу (:
Но тема для размышлений интересная.