The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Правильное оформление информации выбранной из БД"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы WEB технологии (Public)
Изначальное сообщение [Проследить за развитием треда]

"Правильное оформление информации выбранной из БД"  
Сообщение от realovich email on 22-Окт-07, 19:46 
Опишу ситуацию:
Есть таблица БД следующего вида:

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, поэтому сильно не бейте, если вопрос глупый. Очень надеюсь, что поможете...
Заранее благодарен!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Правильное оформление информации выбранной из БД"  
Сообщение от angra (ok) on 23-Окт-07, 23:22 
Если уж создана такая безграмотная таблица, то остается использовать либо pos либо регэкспы для вычленения нужной подстроки в subcategory
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Правильное оформление информации выбранной из БД"  
Сообщение от tux2002 email on 24-Окт-07, 17:37 
По тупому

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')


База то какая?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Правильное оформление информации выбранной из БД"  
Сообщение от realovich email on 25-Окт-07, 08:43 
>[оверквотинг удален]
>   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)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Правильное оформление информации выбранной из БД"  
Сообщение от angra (ok) on 25-Окт-07, 09:02 
>По тупому

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Правильное оформление информации выбранной из БД"  
Сообщение от tux2002 email on 25-Окт-07, 11:35 
>>По тупому
>
>Однозначно. Зачем нагружать сервер такими запросами, когда нужный результат может быть получен
>за счет простейшей обработки строк в программе? Наделают таких вот безграмотных
>баз с извращенными запросами, а потом начинаются претензии к хостеру что
>сервер БД тормозит.

В explain_plan нужно заглядывать. Четыре объёдинённых простых запроса это уже верх нагрузки :).

Этот запрос на 400000 записях выполняется 0.00 - 0.03. Остальное fetch row. База на простом PC.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Правильное оформление информации выбранной из БД"  
Сообщение от angra (ok) on 26-Окт-07, 09:11 
А если это не единственный запрос? что если подобных запросов идет несколько сотен в секунду? Зачем зря нагружать сервер БД, учитывая что это очень часто самое слабое звено?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Правильное оформление информации выбранной из БД"  
Сообщение от tux2002 email on 26-Окт-07, 09:19 
>А если это не единственный запрос? что если подобных запросов идет несколько
>сотен в секунду? Зачем зря нагружать сервер БД, учитывая что это
>очень часто самое слабое звено?

Да фигня запрос, выглядит только так.
Если Вы работаете с Oracle например Вы должны понимать что такой запрос по сравнению с прстым селектом из той же таблицы почти одно и то же по дисковым операциям а разбор такого запроса это семечки для Oracle.
На то и БД чтоб работать а не проц в холостую гонять.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Правильное оформление информации выбранной из БД"  
Сообщение от angra (ok) on 27-Окт-07, 05:46 
Вы в курсе что есть и другие БД? А что такое shared hosting? У нас с вами разный опыт. Когда то давно я тоже сбрасывал логику на БД, но с тех пор встретил много примеров где этого делать нельзя.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Правильное оформление информации выбранной из БД"  
Сообщение от andy email(??) on 27-Окт-07, 08:47 
>Вы в курсе что есть и другие БД? А что такое shared
>hosting? У нас с вами разный опыт. Когда то давно я
>тоже сбрасывал логику на БД, но с тех пор встретил много
>примеров где этого делать нельзя.

*Чел сидит и ест пельмени ложкой, подходит второй*
- возьми вилку, ей же удобней
- Вилка фигня
- ??? Ей же действительно удобней
- А вы в курсе, что есть суп? У нас с вами разный опыт. Я встречал кучу примеров, где вилкой пользоваться нельзя

Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет этого делать, то это его частные проблемы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Правильное оформление информации выбранной из БД"  
Сообщение от angra (ok) on 27-Окт-07, 10:47 
>Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет
>этого делать, то это его частные проблемы.

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Правильное оформление информации выбранной из БД"  
Сообщение от andy email(??) on 29-Окт-07, 07:21 
>Думать и тестировать товарищ надо ... Если конкретный разработчик этого не понимает, то это
>его частные проблемы.

Золотые слова

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Правильное оформление информации выбранной из БД"  
Сообщение от tux2002 email on 29-Окт-07, 08:38 
>>Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет
>>этого делать, то это его частные проблемы.
>
>И зачем тогда программы для работы с БД писать, ведь всю логику
>надо запихнуть в базу, напишем один раз универсальный пользовательский интерфейс и
>все на этом.
>Думать и тестировать товарищ надо, а не слепо следовать каким либо концепциям.
>Иногда лучше логику передавать в базу, иногда на серверное приложение, иногда
>на клиентскую часть. Если конкретный разработчик этого не понимает, то это
>его частные проблемы.

На это можно ответить следующее. По моему опыту для клиента база должна иметь однин и тот же функционал как для sql-plus так и для приложения forms/qt/delphi/java и т.д. Если Вы что-то связанное хотя бы с целостностью данных переносите на приложение, будьте готовы что какой нибудь умник sql-клиентом наколобасит что захочет мимо Ваших проверок в приложении. Поэтому логика зачастую и уходит почти целиком на уровень БД.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Правильное оформление информации выбранной из БД"  
Сообщение от angra (ok) on 29-Окт-07, 10:43 
Абсолютно с вами согласен, что этот подход имеет свои преимущества. Более того он полезен даже при условии, что с базой вся работа идет только через приложение. Если приложение сложное да еще и разрабатывается несколькими людьми, то логика в БД защитит от многих ошибок. Однако согласитесь и вы, что иногда производительность становится основным критерием и, когда это случается, красота и надежность интерфейса с базой отходят на второй план. В таких случаях логику имеет смысл ставить туда, где она быстрее работает и/или легче масштабируема, а будет ли это БД или приложение зависит от многих условий.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Правильное оформление информации выбранной из БД"  
Сообщение от tux2002 email on 29-Окт-07, 14:28 
>Абсолютно с вами согласен, что этот подход имеет свои преимущества. Более того
>он полезен даже при условии, что с базой вся работа идет
>только через приложение. Если приложение сложное да еще и разрабатывается несколькими
>людьми, то логика в БД защитит от многих ошибок. Однако согласитесь
>и вы, что иногда производительность становится основным критерием и, когда это
>случается, красота и надежность интерфейса с базой отходят на второй план.
>В таких случаях логику имеет смысл ставить туда, где она быстрее
>работает и/или легче масштабируема, а будет ли это БД или приложение
>зависит от многих условий.

Я конечно соглашусь. Бывают правда случаи когда клиентское приложение мигрируют с одной технологии на другую. Сидели мы на формс, начальству вздумалось веб. Чем больше предыдущий разработчик заложил в базу и задокументировал, тем проще следующему. А оптимизация в меру сил. Если политика начальства заключается в том, что лучше купить сервера, чем повышать зарплату, то и выводы соответствующие - как проще себе.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру