Опишу ситуацию:
Есть таблица БД следующего вида:date | name | category |cat_id| subcategory | sub_id
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
01.10.07 | Иванов И. | Дежурство на проходной | 1 | Дежурство на проходной. Ответственный (Утро) | 1
01.10.07 | Сидоров С. | Дежурство на проходной | 1 | Дежурство на проходной. Помощник (Утро) | 2
01.10.07 | Петров П. | Дежурство на проходной | 1 | Дежурство на проходной. Ответственный (Вечер) | 3
01.10.07 | Максимов М. | Дежурство на проходной | 1 | Дежурство на проходной. Помощник (Вечер) | 4Информация средствами php попадает в календарь, в определённую ячейку дня недели, в данном случае 1 октября 2007 года. Календарь уже есть.
Нужно только оформить вид ячейки с информацией. Но выводить название категории или подкатегории не очень удобно, да и не нужно в некоторых случаях, так как название категории попадает в заголовок над календарём.
Нужно, чтобы в ячейке появлялась примерно следующая информация:Утро (8:00 - 12:00)
Иванов И.
Сидоров С.
Вечер (13:00 - 17:00)
Петров П.
Максимов М.Естественно первая фамилия сама по себе означает что это ответственный...
Помогите оформить такой вывод... Я новичок в php, поэтому сильно не бейте, если вопрос глупый. Очень надеюсь, что поможете...
Заранее благодарен!
Если уж создана такая безграмотная таблица, то остается использовать либо pos либо регэкспы для вычленения нужной подстроки в subcategory
По тупомуSELECT 'Утро (8:00 - 12:00)'
FROM DUAL
UNION ALL
SELECT name
FROM test
WHERE subcategory LIKE '%Ответственный%'
AND subcategory LIKE '%Утро%'
AND TRUNC (DATA) = TO_DATE ('24.10.2007', 'DD.MM.YYYY')
UNION ALL
SELECT name
FROM test
WHERE subcategory LIKE '%Помощник%'
AND subcategory LIKE '%Утро%'
AND TRUNC (DATA) = TO_DATE ('24.10.2007', 'DD.MM.YYYY')
UNION ALL
SELECT 'Вечер (13:00 - 17:00)'
FROM DUAL
UNION ALL
SELECT name
FROM test
WHERE subcategory LIKE '%Ответственный%'
AND subcategory LIKE '%Вечер%'
AND TRUNC (DATA) = TO_DATE ('24.10.2007', 'DD.MM.YYYY')
UNION ALL
SELECT name
FROM test
WHERE subcategory LIKE '%Помощник%'
AND subcategory LIKE '%Вечер%'
AND TRUNC (DATA) = TO_DATE ('24.10.2007', 'DD.MM.YYYY')
База то какая?
>[оверквотинг удален]
> AND TRUNC (DATA) = TO_DATE ('24.10.2007', 'DD.MM.YYYY')
>UNION ALL
>SELECT name
> FROM test
> WHERE subcategory LIKE '%Помощник%'
> AND subcategory LIKE '%Вечер%'
> AND TRUNC (DATA) = TO_DATE ('24.10.2007', 'DD.MM.YYYY')
>
>
>База то какая?Неплохая мысль... Спасибо! База данных SQL (Microsoft)
>По тупомуОднозначно. Зачем нагружать сервер такими запросами, когда нужный результат может быть получен за счет простейшей обработки строк в программе? Наделают таких вот безграмотных баз с извращенными запросами, а потом начинаются претензии к хостеру что сервер БД тормозит.
>>По тупому
>
>Однозначно. Зачем нагружать сервер такими запросами, когда нужный результат может быть получен
>за счет простейшей обработки строк в программе? Наделают таких вот безграмотных
>баз с извращенными запросами, а потом начинаются претензии к хостеру что
>сервер БД тормозит.В explain_plan нужно заглядывать. Четыре объёдинённых простых запроса это уже верх нагрузки :).
Этот запрос на 400000 записях выполняется 0.00 - 0.03. Остальное fetch row. База на простом PC.
А если это не единственный запрос? что если подобных запросов идет несколько сотен в секунду? Зачем зря нагружать сервер БД, учитывая что это очень часто самое слабое звено?
>А если это не единственный запрос? что если подобных запросов идет несколько
>сотен в секунду? Зачем зря нагружать сервер БД, учитывая что это
>очень часто самое слабое звено?Да фигня запрос, выглядит только так.
Если Вы работаете с Oracle например Вы должны понимать что такой запрос по сравнению с прстым селектом из той же таблицы почти одно и то же по дисковым операциям а разбор такого запроса это семечки для Oracle.
На то и БД чтоб работать а не проц в холостую гонять.
Вы в курсе что есть и другие БД? А что такое shared hosting? У нас с вами разный опыт. Когда то давно я тоже сбрасывал логику на БД, но с тех пор встретил много примеров где этого делать нельзя.
>Вы в курсе что есть и другие БД? А что такое shared
>hosting? У нас с вами разный опыт. Когда то давно я
>тоже сбрасывал логику на БД, но с тех пор встретил много
>примеров где этого делать нельзя.*Чел сидит и ест пельмени ложкой, подходит второй*
- возьми вилку, ей же удобней
- Вилка фигня
- ??? Ей же действительно удобней
- А вы в курсе, что есть суп? У нас с вами разный опыт. Я встречал кучу примеров, где вилкой пользоваться нельзяМораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет этого делать, то это его частные проблемы.
>Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет
>этого делать, то это его частные проблемы.И зачем тогда программы для работы с БД писать, ведь всю логику надо запихнуть в базу, напишем один раз универсальный пользовательский интерфейс и все на этом.
Думать и тестировать товарищ надо, а не слепо следовать каким либо концепциям. Иногда лучше логику передавать в базу, иногда на серверное приложение, иногда на клиентскую часть. Если конкретный разработчик этого не понимает, то это его частные проблемы.
>Думать и тестировать товарищ надо ... Если конкретный разработчик этого не понимает, то это
>его частные проблемы.Золотые слова
>>Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет
>>этого делать, то это его частные проблемы.
>
>И зачем тогда программы для работы с БД писать, ведь всю логику
>надо запихнуть в базу, напишем один раз универсальный пользовательский интерфейс и
>все на этом.
>Думать и тестировать товарищ надо, а не слепо следовать каким либо концепциям.
>Иногда лучше логику передавать в базу, иногда на серверное приложение, иногда
>на клиентскую часть. Если конкретный разработчик этого не понимает, то это
>его частные проблемы.На это можно ответить следующее. По моему опыту для клиента база должна иметь однин и тот же функционал как для sql-plus так и для приложения forms/qt/delphi/java и т.д. Если Вы что-то связанное хотя бы с целостностью данных переносите на приложение, будьте готовы что какой нибудь умник sql-клиентом наколобасит что захочет мимо Ваших проверок в приложении. Поэтому логика зачастую и уходит почти целиком на уровень БД.
Абсолютно с вами согласен, что этот подход имеет свои преимущества. Более того он полезен даже при условии, что с базой вся работа идет только через приложение. Если приложение сложное да еще и разрабатывается несколькими людьми, то логика в БД защитит от многих ошибок. Однако согласитесь и вы, что иногда производительность становится основным критерием и, когда это случается, красота и надежность интерфейса с базой отходят на второй план. В таких случаях логику имеет смысл ставить туда, где она быстрее работает и/или легче масштабируема, а будет ли это БД или приложение зависит от многих условий.
>Абсолютно с вами согласен, что этот подход имеет свои преимущества. Более того
>он полезен даже при условии, что с базой вся работа идет
>только через приложение. Если приложение сложное да еще и разрабатывается несколькими
>людьми, то логика в БД защитит от многих ошибок. Однако согласитесь
>и вы, что иногда производительность становится основным критерием и, когда это
>случается, красота и надежность интерфейса с базой отходят на второй план.
>В таких случаях логику имеет смысл ставить туда, где она быстрее
>работает и/или легче масштабируема, а будет ли это БД или приложение
>зависит от многих условий.Я конечно соглашусь. Бывают правда случаи когда клиентское приложение мигрируют с одной технологии на другую. Сидели мы на формс, начальству вздумалось веб. Чем больше предыдущий разработчик заложил в базу и задокументировал, тем проще следующему. А оптимизация в меру сил. Если политика начальства заключается в том, что лучше купить сервера, чем повышать зарплату, то и выводы соответствующие - как проще себе.