У меня имеется таблица со столбцами дней месяца, мне нужно выбрать три последних дня, независимо

от количества дней в месяце. Есть ли элегантный способ решения данной задачи ?

LastDateInMonth = DateAdd(day,-1,DateAdd(month,1,FirstDateInMonth))

Akina, твой вариант возвращает значение последних чисел месяца, а я хочу найти метод выборки

данных последних столбцов в таблице, не зная их общего количества количества.

т.е. месяца мы не знаем? только день? 

 да сколько дней в месяце нам не известно, нужно получить три последних столбца в таблице.

Т.е. если февральская таблица значит day_27, day_28, day_29 и в таком духе для других месяцев.

ЗЫ:

Вообще мне пришла мысль чтоб брать 31 день если ошибка, 30 и т.д. пока не пропустит и потом уменьшать

счетчик от 3-х до нуля. Буду пробовать. Жду других вариантов.

Денормализованная таблица - источник геморроя.
В рамках SQL задача не решается.
Пора указать диалект SQL...

т.е. номер месяца определяется только именем таблицы? 
отлично. тогда ты же запрос где-то формируешь? вот и определяй там, где формируешь запрос, сколько дней в месяце.
а что? ты же сам выбрал такой 

может, переделаешь в нормальную структуру? 

С чего ты это решил. База данных нормализирована по всем трем формам.



Понял, спасибо.



Незнаю, база данных MySQL.

ЗЫ:
Всетаки не теряю надежды на решение этой задачи средствами SQL.

Буду рад приведенным примерам.

Цель базы данных состоит в том чтоб хранить в себе сформированный график выходов рабочих. При 

добавлении нового рабочего в базу данных формируется график выходов на весь год.

Я пользуюсь таблицами, "рабочие" и 12 таблиц для каждого месяца. Связь идет через поле табельного номера.

Подскажите мне, что именно нужно нормализировать для повышения эффективности ?

1 таблица на все 12 месяцев поля: таб№, дата, признаки всякие. Т.е. не day_1,  day_2, day_3, day_4, ... day_30, day_31 а по вертикали, где будет полная, нормальная дата.
А для отображения на клиенте крути как хочешь.

Deniz, ты предлагаешь создать таблицу:
_______|Январь|Февраль|Март|...|
1 число  |\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
2 число  |\\\\\\\\\\\" ДАННЫЕ " \\\\\\\
... число |\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

А как ее связать с конкретным человеком по табельному № ? 

Создавать для каждого рабочего свою таблицу ?

знаешь, ты не прав.

нет. опять придешь к тому же. но только если количество дней в месяце <= 31, то рабочих будет.... ээээ.... ну. тебе виднее, сколько будет рабочих.

задача все ещё не ясна. что есть, что надо сформировать и что выдать на выходе?

У тебя есть одна сущность - количество рабочих часов (ну или чего там) в определенном дне для определенного работника. Она у тебя хранится в нескольких полях нескольких таблиц. И ты осмеливаешься ЭТО называть нормализацией???



Структура таблицы такая:

• ID
• Worker_ID (видимо, таб. номер)
• Date (дата)
• Stored_Data (информация на работника на эту дату - скажем, количество раб. часов)

Можно не вводить поле ID, используя в качестве первичного индекса комбинацию полей Worker_ID и Date... хотя я бы не стал этого делать. А вот в зависимости от того, какие запросы на выборку в базу будут наиболее часты, строил бы от 1 до 4 индексов по полям Worker_ID и Date по отдельности или вместе в различном порядке. Индекс ускорит работу. Лишний индекс - замедлит. Ищи оптимум.

Да я имею несколько таблиц вместо одной и я думаю что если количество рабочих будет несколько тыс.

то работать с отдельной таблицей(напр. на 10000 записей) будет рациональнее чем с одной общей (на 120 000 записей)



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



На выходе мне нужно сформировать график выходных и рабочих дней трудящихся, спланировав его на год

ЗЫ:
Вообщето вопрос состоял не о нормализации моей БД (хотя об этом я хотел поговорить несколько позже),

а о вопросе получения данных, но если ответ прозвучавший ранее "о невозможности " окончательный

тогда буду   дальше.   

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

120 тыс. записей даже для Аксесса не нагрузка, а уж для MySQL, да еще таких простеньких - вообще семечки.

Осмелюсь предположить, что сперва надо подучить теорию, а потом думать. И только после этого - делать. Уж извини...


Это сообщение отредактировал(а) Akina - 3.6.2008, 16:47