Есть такое, особенно оракловый SQL Developer. А вот PL/SQL developer достаточно шустрый, что особенно в нем нравится — автоматическое создание новых коннектов к базе для нового окна. Не нравится — не может делать одновременных коннектов к разным базам.
Перед Java-вскими IDE не стоит задачи отображения результатов запроса, а он может быть очень большим и отжирать много памяти.
Биллинговые системы у Опсосов, крутящиеся на Оракле, всю логику имеют в базе — куча пакетов, процедур и функций, зачастую заврапленные с непонятными наименованиями вида kk_576_ml и т.д. Сотни пакетов и продур, тысячи таблиц, миллионы строк кода.
И все работает. И очень даже переносимо/обновляемо/разворачиваемо.
А я вот рад этому нововведению. На гмэйле и на яндексе у меня в названии почты ники, не успел имя.фамилия зарегить — разобрали, а на фейсбуке — как раз имя.фамилия. Так что я получил нормальный ящик, который буду указывать во всех официальных документах, типа резюме.
Попробовал из фейсбука отправить обычное письмо на яндекс — пришло подобие стандартных фейсбуковских уведомлений — синяя плашка с фотографией и ссылкой на профиль и текст письма сбоку. Ну, и подпись снизу «Отправлено через фейсбук».
Так что жду возможность забирать почту по pop3 в гугл и отправлять с нее нормальные письма plain text, без дописок фейбука.
чтобы использовать rownum, надо это дело оборачивать в подзапрос. А теперь представьте, что джойните три такие таблицы. И с этими rownum начинается такая свистопляска, что мама не горюй.
У нас используется метод 2. Для аудита всех таблиц ведется одна отдельная большая партиционированная таблица с инфо о том, кто изменил (ip, машина, логин, и т.д.), имеющая ссылки на измененную таблицу и id измененного объекта. По прошествии времени старые партиции отправляются в архив.
Вообще-то нужно, иначе любой запрос на версию от конкретной даты будет возвращать курсор с кучей значений, которые надо еще отсортировать по DATE_END, и выдать только первый вариант.
А теперь, допустим у Вас есть Oracle, в котором нет LIMIT, и надо связать 3 таблицы с такой версионностью без DATE_START. Тяжело будет написать и долго будет обрабатываться.
А, тут же не nested_loops, а hash join. Тогда да — один раз прочитать то, один раз другое, и джойн по хешу.
«Потому что у него есть статистика, которая говорит, что будут задействованы все значения, а не только часть — поэтому выгоднее прочитать сто строк в память.» — сто каких строк он будет читать? Сто первых строк из Cities? Сомневаюсь.
Народ, а почему никто не смотрит на план выполнения запроса? Он же не просто так приведен.
Смотрим — насколько я понимаю (не спец в SQLServer), он делает Full Scan Cities, затем по индексу приджойнивает таблицу People.
А нам, по идее, — нужно сделать наоборот — один раз пройтись по People, при этом джойня (по индексу) таблицу Cities, затем отсортировать и выбрать 100 первых.
В оракле было бы так:
select person, city from
(select /*+ ordered use_nl(p c) index(c cities$cityid) */
rownum r, p.name person, c.name city
from person p left join cities c on p.cityid = c.cityid
order by c.name)
where r <= 100
p.s.: сущности именуются в именительном падеже (City, а не Cities)
Большинство ошибок валидации связано с отсутствием DocType, и как следствие — все устаревшие теги считаются ошибочными. Ну и отсутствие аттрибута alt у картинок - повсеместные ошибки.
Не думаю, что валидность кода на 100% — показатель качества работы студии.
«We don't index every one of those trillion pages many of them are similar to each other, or represent auto-generated content similar to the calendar example that isn't very useful to searchers. But we're proud to have the most comprehensive index of any search engine, and our goal always has been to index all the world's data.»
что значит «знает, но не индексирует»? Если знает, значит по ним будет произведен поиск. Поиск по индексу, значит проиндексировано. Не сохраняет в кеше - возможно. Но индексирует. Страницы вида index.php?id=1¶m1=value1... и т.д. - не рассматриваются.
Кстати, с гугла убрали надписать «Поиск по стольки-то веб-страницам».
We’ll be back soon...
Due to overwhelming interest, our Cuil servers are running a bit hot right now. The search engine is momentarily unavailable as we add more capacity.
Thanks for your patience.
Перед Java-вскими IDE не стоит задачи отображения результатов запроса, а он может быть очень большим и отжирать много памяти.
Там даже дебаггинг есть, и SVN прикручен к SQL Developer.
И все работает. И очень даже переносимо/обновляемо/разворачиваемо.
Попробовал из фейсбука отправить обычное письмо на яндекс — пришло подобие стандартных фейсбуковских уведомлений — синяя плашка с фотографией и ссылкой на профиль и текст письма сбоку. Ну, и подпись снизу «Отправлено через фейсбук».
Так что жду возможность забирать почту по pop3 в гугл и отправлять с нее нормальные письма plain text, без дописок фейбука.
А теперь, допустим у Вас есть Oracle, в котором нет LIMIT, и надо связать 3 таблицы с такой версионностью без DATE_START. Тяжело будет написать и долго будет обрабатываться.
А если NULLы не нужны — зачем заморачиваться с left join'aми — inner join и будет быстро работать.
«Потому что у него есть статистика, которая говорит, что будут задействованы все значения, а не только часть — поэтому выгоднее прочитать сто строк в память.» — сто каких строк он будет читать? Сто первых строк из Cities? Сомневаюсь.
Смотрим — насколько я понимаю (не спец в SQLServer), он делает Full Scan Cities, затем по индексу приджойнивает таблицу People.
А нам, по идее, — нужно сделать наоборот — один раз пройтись по People, при этом джойня (по индексу) таблицу Cities, затем отсортировать и выбрать 100 первых.
В оракле было бы так:
p.s.: сущности именуются в именительном падеже (City, а не Cities)
Идем на www.youtube.com/watch?v=HFe6oqtjD_ — длительность 04:25.
Там же жмем на «Просмотреть в отдельном окне» — открывается флеш-плеер и там длительность 04:26.
Проверил на 2х видео-роликах.
Не думаю, что валидность кода на 100% — показатель качества работы студии.
«We don't index every one of those trillion pages many of them are similar to each other, or represent auto-generated content similar to the calendar example that isn't very useful to searchers. But we're proud to have the most comprehensive index of any search engine, and our goal always has been to index all the world's data.»
Кстати, с гугла убрали надписать «Поиск по стольки-то веб-страницам».
We’ll be back soon...
Due to overwhelming interest, our Cuil servers are running a bit hot right now. The search engine is momentarily unavailable as we add more capacity.
Thanks for your patience.
Да, Гугл индексирует триллион страниц.