Налицо усложненный микро-цикл разработки, который девелопер «прокручивает» несколько раз до получения нужного результата.
А.
— Пишем SQL-код
— Запускаем, видим результат и ошибки
— Повторяем
Б.
— Пишем Java-код с аннотациями (раза в 2 больше по объему)
— Компилируем
— Запускаем
— Берем полученный файл, добавляем в приложение, компилируем
— Запускаем, видим результат и ошибки
— Повторяем
Если в варианте «Б» что-то вышло не так, то придется восстановить в голове обратную цепочку и понять, что же нужно исправить в исходных аннотациях, чтобы получился нужный SQL.
Согласен! DLNA не так гламурен, зато работает (почти) всегда. Воткнул сетевой кабель в телек и все. В качестве сервера использую Serviio (http://www.serviio.org), неплохой еще «PS3 Media Server». Работает на Windows, Mac, Linux.
Многие NAS-устройствах поддерживают то же самое «из коробки».
Сам люблю и использую Нокии, но откровенно говоря браузер с 5800 сравнивать с iPhone не хочется… Стыдно :( И Опера туда же. Как-то всё работает, но ощущения безупречности нет и бизко.
Вот не пойму — зачем писать перевод, если переводить не умеете? Дали бы просто ссылку на оригинал и не позорились. А то «feature phone» превращается в «специализированный телефон» и появляются «приступы припадка».
Да, и говоря «Hey look, another web browser with WebKit guts» автор совсем не имел ввиду, что «Nokia пустила в опенсорс свой браузер для S60».
Я не наговариваю, я реалист :) Параллелится всё на раз, в каких-то ситуациях становится лучше в разы. В каких-то — хуже в разы, из-за большого оверхеда на создание параллельных потоков обработки и синхронизацию между ними.
Приходится где-то разрешать параллельную обработку, где-то запрещать, где-то переписывать запросы.
В общем, появляется много новой интересной работы :)
А уж какой overhead добавляется при разработке приложения! Нужно по всем запросам к секционированным таблицам 3-жды проверять планы, условия поиска, думать о том, разрешать ли Ораклу распараллеливать их, и т.д.
Маловато будет! Скорее всего ведь процессорные лицензии потребуются, а это 8500 на каждый сокет. Не считая, опять же, поддержки и самой СУБД.
Но по опыту — когда при использовании БД на Oracle встает вопрос секционирования, то речь идет о реально огромной БД, сотни Гб. А значит и железо серьезное, и система ценная. Приходится раскошеливаться.
У них есть кластеризация с высокой доступностью, есть возможность использовать дополнительные серверы в режиме только для чтения (для отчетов, например). Но во всех вариантах изменение данных — только на одном сервере. Так что для серьезного масштабирования в OLTP-задачах придется разбивать данные на несколько отдельных БД. Ну или покупать мейнфрейм :)
1. EntLib DAAB избавит от большей части банального кода
2. Использование ODP.NET вместо System.Data.OracleClient в нашем случае улучшило скорость работы с CLOB-полями в РАЗЫ
MS не зря прекращает разработку своего .NET-провайдера Oracle. Нет смысла его разрабатывать (и использовать!!!), если есть родной ODP.NET, который и гораздо быстрее, и лучше поддерживает специфические возможности Оракла.
Бесплатный вариант nCache не имеет ни тегирования, ни вообще каких-либо dependencies, кроме file-based. А платный выходит от $1000 на каждый CPU, т.е. — от $2000 на минимальную конфигурацию из 2х серверов…
Velocity пока на такой стадии, что пользоваться им сложно. Плюс обычное желание Майкрософта «объять необъятное» вместо того, чтобы сделать простую версию 1.0, решающую проблемы «здесь и сейчас».
Так что пока — только Memcached + самописная работа с тегами :(
А.
— Пишем SQL-код
— Запускаем, видим результат и ошибки
— Повторяем
Б.
— Пишем Java-код с аннотациями (раза в 2 больше по объему)
— Компилируем
— Запускаем
— Берем полученный файл, добавляем в приложение, компилируем
— Запускаем, видим результат и ошибки
— Повторяем
Если в варианте «Б» что-то вышло не так, то придется восстановить в голове обратную цепочку и понять, что же нужно исправить в исходных аннотациях, чтобы получился нужный SQL.
Многие NAS-устройствах поддерживают то же самое «из коробки».
За будущее мира спокоен теперь я
Да, и говоря «Hey look, another web browser with WebKit guts» автор совсем не имел ввиду, что «Nokia пустила в опенсорс свой браузер для S60».
Приходится где-то разрешать параллельную обработку, где-то запрещать, где-то переписывать запросы.
В общем, появляется много новой интересной работы :)
Но по опыту — когда при использовании БД на Oracle встает вопрос секционирования, то речь идет о реально огромной БД, сотни Гб. А значит и железо серьезное, и система ценная. Приходится раскошеливаться.
У них есть кластеризация с высокой доступностью, есть возможность использовать дополнительные серверы в режиме только для чтения (для отчетов, например). Но во всех вариантах изменение данных — только на одном сервере. Так что для серьезного масштабирования в OLTP-задачах придется разбивать данные на несколько отдельных БД. Ну или покупать мейнфрейм :)
1. EntLib DAAB избавит от большей части банального кода
2. Использование ODP.NET вместо System.Data.OracleClient в нашем случае улучшило скорость работы с CLOB-полями в РАЗЫ
Velocity пока на такой стадии, что пользоваться им сложно. Плюс обычное желание Майкрософта «объять необъятное» вместо того, чтобы сделать простую версию 1.0, решающую проблемы «здесь и сейчас».
Так что пока — только Memcached + самописная работа с тегами :(