- Правильное оформление информации выбранной из БД,
 angra, 23:22 , 23-Окт-07 (1)Если уж создана такая безграмотная таблица, то остается использовать либо pos либо регэкспы для вычленения нужной подстроки в subcategory
- Правильное оформление информации выбранной из БД, tux2002, 17:37 , 24-Окт-07 (2)
По тупому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')
База то какая?
- Правильное оформление информации выбранной из БД, realovich, 08:43 , 25-Окт-07 (3)
>[оверквотинг удален]
> 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)
- Правильное оформление информации выбранной из БД, angra, 09:02 , 25-Окт-07 (4)
>По тупому Однозначно. Зачем нагружать сервер такими запросами, когда нужный результат может быть получен за счет простейшей обработки строк в программе? Наделают таких вот безграмотных баз с извращенными запросами, а потом начинаются претензии к хостеру что сервер БД тормозит.
- Правильное оформление информации выбранной из БД, tux2002, 11:35 , 25-Окт-07 (5)
>>По тупому
>
>Однозначно. Зачем нагружать сервер такими запросами, когда нужный результат может быть получен
>за счет простейшей обработки строк в программе? Наделают таких вот безграмотных
>баз с извращенными запросами, а потом начинаются претензии к хостеру что
>сервер БД тормозит.В explain_plan нужно заглядывать. Четыре объёдинённых простых запроса это уже верх нагрузки :). Этот запрос на 400000 записях выполняется 0.00 - 0.03. Остальное fetch row. База на простом PC.
- Правильное оформление информации выбранной из БД, angra, 09:11 , 26-Окт-07 (6)
А если это не единственный запрос? что если подобных запросов идет несколько сотен в секунду? Зачем зря нагружать сервер БД, учитывая что это очень часто самое слабое звено?
- Правильное оформление информации выбранной из БД, tux2002, 09:19 , 26-Окт-07 (7)
>А если это не единственный запрос? что если подобных запросов идет несколько
>сотен в секунду? Зачем зря нагружать сервер БД, учитывая что это
>очень часто самое слабое звено? Да фигня запрос, выглядит только так.
Если Вы работаете с Oracle например Вы должны понимать что такой запрос по сравнению с прстым селектом из той же таблицы почти одно и то же по дисковым операциям а разбор такого запроса это семечки для Oracle.
На то и БД чтоб работать а не проц в холостую гонять.
- Правильное оформление информации выбранной из БД, angra, 05:46 , 27-Окт-07 (8)
Вы в курсе что есть и другие БД? А что такое shared hosting? У нас с вами разный опыт. Когда то давно я тоже сбрасывал логику на БД, но с тех пор встретил много примеров где этого делать нельзя.
- Правильное оформление информации выбранной из БД, andy, 08:47 , 27-Окт-07 (9)
>Вы в курсе что есть и другие БД? А что такое shared
>hosting? У нас с вами разный опыт. Когда то давно я
>тоже сбрасывал логику на БД, но с тех пор встретил много
>примеров где этого делать нельзя. *Чел сидит и ест пельмени ложкой, подходит второй*
- возьми вилку, ей же удобней
- Вилка фигня
- ??? Ей же действительно удобней
- А вы в курсе, что есть суп? У нас с вами разный опыт. Я встречал кучу примеров, где вилкой пользоваться нельзя Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет этого делать, то это его частные проблемы.
- Правильное оформление информации выбранной из БД, angra, 10:47 , 27-Окт-07 (10)
>Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет
>этого делать, то это его частные проблемы. И зачем тогда программы для работы с БД писать, ведь всю логику надо запихнуть в базу, напишем один раз универсальный пользовательский интерфейс и все на этом.
Думать и тестировать товарищ надо, а не слепо следовать каким либо концепциям. Иногда лучше логику передавать в базу, иногда на серверное приложение, иногда на клиентскую часть. Если конкретный разработчик этого не понимает, то это его частные проблемы.
- Правильное оформление информации выбранной из БД, andy, 07:21 , 29-Окт-07 (11)
>Думать и тестировать товарищ надо ... Если конкретный разработчик этого не понимает, то это
>его частные проблемы. Золотые слова
- Правильное оформление информации выбранной из БД, tux2002, 08:38 , 29-Окт-07 (12)
>>Мораль: логика _должна_ быть в БД. Если некий конкретный пример не позволяет
>>этого делать, то это его частные проблемы.
>
>И зачем тогда программы для работы с БД писать, ведь всю логику
>надо запихнуть в базу, напишем один раз универсальный пользовательский интерфейс и
>все на этом.
>Думать и тестировать товарищ надо, а не слепо следовать каким либо концепциям.
>Иногда лучше логику передавать в базу, иногда на серверное приложение, иногда
>на клиентскую часть. Если конкретный разработчик этого не понимает, то это
>его частные проблемы. На это можно ответить следующее. По моему опыту для клиента база должна иметь однин и тот же функционал как для sql-plus так и для приложения forms/qt/delphi/java и т.д. Если Вы что-то связанное хотя бы с целостностью данных переносите на приложение, будьте готовы что какой нибудь умник sql-клиентом наколобасит что захочет мимо Ваших проверок в приложении. Поэтому логика зачастую и уходит почти целиком на уровень БД.
- Правильное оформление информации выбранной из БД, angra, 10:43 , 29-Окт-07 (13)
Абсолютно с вами согласен, что этот подход имеет свои преимущества. Более того он полезен даже при условии, что с базой вся работа идет только через приложение. Если приложение сложное да еще и разрабатывается несколькими людьми, то логика в БД защитит от многих ошибок. Однако согласитесь и вы, что иногда производительность становится основным критерием и, когда это случается, красота и надежность интерфейса с базой отходят на второй план. В таких случаях логику имеет смысл ставить туда, где она быстрее работает и/или легче масштабируема, а будет ли это БД или приложение зависит от многих условий.
- Правильное оформление информации выбранной из БД, tux2002, 14:28 , 29-Окт-07 (14)
>Абсолютно с вами согласен, что этот подход имеет свои преимущества. Более того
>он полезен даже при условии, что с базой вся работа идет
>только через приложение. Если приложение сложное да еще и разрабатывается несколькими
>людьми, то логика в БД защитит от многих ошибок. Однако согласитесь
>и вы, что иногда производительность становится основным критерием и, когда это
>случается, красота и надежность интерфейса с базой отходят на второй план.
>В таких случаях логику имеет смысл ставить туда, где она быстрее
>работает и/или легче масштабируема, а будет ли это БД или приложение
>зависит от многих условий. Я конечно соглашусь. Бывают правда случаи когда клиентское приложение мигрируют с одной технологии на другую. Сидели мы на формс, начальству вздумалось веб. Чем больше предыдущий разработчик заложил в базу и задокументировал, тем проще следующему. А оптимизация в меру сил. Если политика начальства заключается в том, что лучше купить сервера, чем повышать зарплату, то и выводы соответствующие - как проще себе.
|
Версия для распечатки
Правильное оформление информации выбранной из БД, 
