Windows Mobile → На Windows Phone 7 портирован SQLite
Прошло всего три дня после анонса подробностей о Windows Phone 7 и инструментов для разработчиков. И вот под новую платформу портировали SQLite. Встроенная в WP7 БД Sql Server Compact пока недоступна для разработчиков, так что такой порт выглядит со всех сторон замечательно. При портировании использовался проект csharp-sqlite (многие ранее спрашивали зачем он нужен).
Блог им. SadHamster → Django, начало работы с базой данных
Знакомство с django, Работа с БД.
На Хабре существует много тем о django, с описанием различных вкусностей. Но мне не встречался пост, про начало пути, так сказать для новичка. Так что хочется написать короткое руководство начинающего бойца, по собственным шагам.
Cпасибо www.djbook.ru, русский перевод онлайн книги о django, именно отсюда я черпал данные для написания поста.
Далее по тексту я попытаюсь кратко описать общие сведения необходимые для работы с БД в django.
Блог им. diod → язык программирования M, он же MUMPS, ДИАМС. параллельная обработка
! привет
.свою сагу начну с упоминания моего учителя и профи языка программирования М и удивительного друга Александра Велиева который ведёт сайт www.cgi2m.net.ua откуда я и копирую со своими комментариями его статью
Я счастлив, что М успешно справился с новым вызовом времени — параллельной обработкой.
Это новейший и абсолютно иной вид программистского мышления.
Начало этой истории — зима 2006 года.
Знакомая попросила для брата-студента книгу о Прологе.
Я разыскал Пролог-библию Братко и наконец решил её прочесть снова.
В ней я прочёл, как элегантно Братко нашёл алгоритм наибольшего общего делителя без вычислений.
Это решение было настолько элегантно, что я решил написать что-либо подобное в М.
Я написал программу на бумаге и боялся её запустить.
Как старый мумпсер я знал о строгих ограничениях на количество подпроцессов и не мог оценить размера базы данных, который для этого понадобится.
Я не хотел начинать испытания такой элегантной и мощной программы с таких вещей, как крах базы данных или отказ компилятора.
Но узнав GT.M лучше, я начал сомневаться в своих сомнениях и решил попросить совета на comp.lang.mumps.
Сразу же г-н. K.S.Bhaskar ответил мне.
Благодаря его советам и поддержке я смог её успешно испытать. Вот код:
Испытания этой программы в GT.M было успешным — об этом Вы можете прочесть на форуме comp.lang.mumps.
.свою сагу начну с упоминания моего учителя и профи языка программирования М и удивительного друга Александра Велиева который ведёт сайт www.cgi2m.net.ua откуда я и копирую со своими комментариями его статью
:: Параллельная обработка :.
Я счастлив, что М успешно справился с новым вызовом времени — параллельной обработкой.
Это новейший и абсолютно иной вид программистского мышления.
Как я боялся своей программы
Начало этой истории — зима 2006 года.
Знакомая попросила для брата-студента книгу о Прологе.
Я разыскал Пролог-библию Братко и наконец решил её прочесть снова.
В ней я прочёл, как элегантно Братко нашёл алгоритм наибольшего общего делителя без вычислений.
Это решение было настолько элегантно, что я решил написать что-либо подобное в М.
Я написал программу на бумаге и боялся её запустить.
Как старый мумпсер я знал о строгих ограничениях на количество подпроцессов и не мог оценить размера базы данных, который для этого понадобится.
Я не хотел начинать испытания такой элегантной и мощной программы с таких вещей, как крах базы данных или отказ компилятора.
Но узнав GT.M лучше, я начал сомневаться в своих сомнениях и решил попросить совета на comp.lang.mumps.
Сразу же г-н. K.S.Bhaskar ответил мне.
Благодаря его советам и поддержке я смог её успешно испытать. Вот код:
;Эта программа создаёт численные ряды ;a - простые числа(делятся на 1 и себя) ;b - ряды делителей ;c - ряд простых чисел example ; k ^a,^b,^c,^pid s Lim=1000000,^p=0,h1=$h f i=2:1:Lim s ^a(i)=i s (i,^c(1))=1 f s i=$o(^a(i)) q:i="" d .j a(i,Lim)::0 i d c .e d a(i,Lim) w Lim,i,! s h2=$h zwr q a(v1,v2) s ^pid($j)=,(^b(v1,v1),^c(v1))=v1,c=v1+v1 i c<v2 f n=c:v1:v2 k ^a(n) s (^b(v1,n),^c(n))=n k ^pid($j) q c k p m p=^pid s c="" f s=0:1 s c=$o(p©) q:c="" s c=$g(p) s:c<s ^pid=s w P ,i, ,s, ,c,! q
Испытания этой программы в GT.M было успешным — об этом Вы можете прочесть на форуме comp.lang.mumps.
SQL → Базы данных. Конфликты параллельного доступа (Часть 1 — поиск проблемы)
Уважаемые коллеги, в данной статье будем рассматривать не виды блокировок в SQL, а способы решения проблем, когда обращаемся к одним и тем же данным из разных подключений, и часть обновлений при этом может быть потеряна. Статья не зависит от конкретной базы данных и может быть одинаково интересна многим.
Всегда может быть такая ситуация, когда в одном соединении мы прочитали какие-то записи, а затем попытались их обновить. Но за момент, пока мы их редактировали, а затем попытались сохранить, в другом соединении эти же записи уже были обновлены. Иначе говоря, первый процесс читает данные, после чего те же данные читает второй процесс, и второй процесс обновляет эти же данные до того, как это сможет сделать первый процесс, то возникнет конфликт, когда первый процесс попытается обновить эти данные.
Если к базе данных обращаться из нескольких соединений и проводить изменения, то возникновение конфликтов — это лишь вопрос времени и везения.
Приложение само должно решать, какие действия ему необходимо сделать, чтобы решить этот конфликт. Например, ситуация может быть такая: администратор сайта зашел на страницу, отображающую данные обычного пользователя (администратор имеет возможность обновлять эти данные).Если после того, как страница администратора прочитает пользовательские данные из базы, и обычный пользователь обратиться к странице, отображающую его пользовательские данных, и внесет измения, то возникнет конфликт, когда администратор сохранит свои изменения. Если же конфликт не возникнет — то изменения обычного пользователя будут перекрыты и потеряны. Может быть и иначе — изменения администратора потеряны. Какое поведение должно быть верным в каждом конкретном случае — это и есть сложная проблема. Первый шаг — обнаружить её. Второй — разрешить. Есть два базовых подхода к разрешению конфликтов параллельного доступа — оптимистичный и пессимистичный.
Всегда может быть такая ситуация, когда в одном соединении мы прочитали какие-то записи, а затем попытались их обновить. Но за момент, пока мы их редактировали, а затем попытались сохранить, в другом соединении эти же записи уже были обновлены. Иначе говоря, первый процесс читает данные, после чего те же данные читает второй процесс, и второй процесс обновляет эти же данные до того, как это сможет сделать первый процесс, то возникнет конфликт, когда первый процесс попытается обновить эти данные.
Если к базе данных обращаться из нескольких соединений и проводить изменения, то возникновение конфликтов — это лишь вопрос времени и везения.
Приложение само должно решать, какие действия ему необходимо сделать, чтобы решить этот конфликт. Например, ситуация может быть такая: администратор сайта зашел на страницу, отображающую данные обычного пользователя (администратор имеет возможность обновлять эти данные).Если после того, как страница администратора прочитает пользовательские данные из базы, и обычный пользователь обратиться к странице, отображающую его пользовательские данных, и внесет измения, то возникнет конфликт, когда администратор сохранит свои изменения. Если же конфликт не возникнет — то изменения обычного пользователя будут перекрыты и потеряны. Может быть и иначе — изменения администратора потеряны. Какое поведение должно быть верным в каждом конкретном случае — это и есть сложная проблема. Первый шаг — обнаружить её. Второй — разрешить. Есть два базовых подхода к разрешению конфликтов параллельного доступа — оптимистичный и пессимистичный.
Высокая производительность → Заметки об использовании MongoDB в реальной системе (сервис Server Density)
Компания Server Density (мониторинг серверов) использует MongoDB для хранения данных уже более 8-ми месяцев, и теперь рассказывают о своем опыте. Это стоит почитать — почти 100 Гб, более 600 млн. документов, 17 тыс. таблиц… для NoSQL это очень даже!
Блог им. orloffkirill → Исправление работы MySQL при поломке innoDB-таблиц
Здравствуйте!
Я (быть может, как и вы) — разработчик сайтов, и мне, чтобы все мои наработки не потерялись нужен SVN. А так как я работаю не один, то еще, как минимум, и общая БД. Несколько лет назад мы приобрели NAS-сервер Synology DS-101 (Tom`s Guide или Nix), устроили там хранилище, включили базу (правда, MySQL4). Несколько лет служил он нам верой и правдой, пережил приход пьяных электриков (когда нас сначала подключили на 380В, а потом спохватились — почти все погорело), но вот… несколько недель назад база не хотела загружаться. Пришлось исправлять.
Все бы ничего, если бы этот случай не повторился…
Я (быть может, как и вы) — разработчик сайтов, и мне, чтобы все мои наработки не потерялись нужен SVN. А так как я работаю не один, то еще, как минимум, и общая БД. Несколько лет назад мы приобрели NAS-сервер Synology DS-101 (Tom`s Guide или Nix), устроили там хранилище, включили базу (правда, MySQL4). Несколько лет служил он нам верой и правдой, пережил приход пьяных электриков (когда нас сначала подключили на 380В, а потом спохватились — почти все погорело), но вот… несколько недель назад база не хотела загружаться. Пришлось исправлять.
Все бы ничего, если бы этот случай не повторился…
Oracle → Томми ответит за всё!
24 февраля в Москву приезжает легендарный фанат и «проповедник» технологий Oracle Том Кайт с серией докладов и семинаров «Ask Tom in Moscow. Hear your answers loud and clear!»
Томас (Том) Кайт — ведущий технический архитектор Департамента серверных технологий компании Oracle (Senior Technical Architect in Oracle’s Server Technology Division).
Томас Кайт стал Томом благодаря своей колонке AskTom в Oracle Magazine, в рамках которой он на протяжении многих лет профессионально занимается решением проблем, возникающих при использовании СУБД Oracle у администраторов и разработчиков по всему миру.
Тому приходится отвечать на десятки вопросов в день. При этом, его комментарии и ответы всегда отличаются информативностью и нестандартностью подхода к решению даже самых простых задач. Это, как правило, приводит очень элегантным и эффективным решениям при разработке приложений и администрировании.
По сути, вся деятельность Тома Кайта направлена на то, чтобы помочь специалистам преодолеть пропасть между простым умением создавать приложения для СУБД Oracle и глубоким пониманием истинных возможностей и потенциала архитектуры СУБД Oracle.
Томас (Том) Кайт — ведущий технический архитектор Департамента серверных технологий компании Oracle (Senior Technical Architect in Oracle’s Server Technology Division). Томас Кайт стал Томом благодаря своей колонке AskTom в Oracle Magazine, в рамках которой он на протяжении многих лет профессионально занимается решением проблем, возникающих при использовании СУБД Oracle у администраторов и разработчиков по всему миру.
Тому приходится отвечать на десятки вопросов в день. При этом, его комментарии и ответы всегда отличаются информативностью и нестандартностью подхода к решению даже самых простых задач. Это, как правило, приводит очень элегантным и эффективным решениям при разработке приложений и администрировании.
По сути, вся деятельность Тома Кайта направлена на то, чтобы помочь специалистам преодолеть пропасть между простым умением создавать приложения для СУБД Oracle и глубоким пониманием истинных возможностей и потенциала архитектуры СУБД Oracle.
Блог им. Staser → Защита персональных данных
Все мы слышали об электронной системе рецептов и медицинских карточках в Эстонии,
В Латвии из электронных систем, пользующихся популярностью есть всего несколько:
Из государственных:
Из частных:
Так вот, сейчас на днях стало известно о том, что националисты собирали фотографии и данные об автомобилистах, использующих на своих автомобилях символику Российской Федерации (флаги, Георгиевские ленты)
И что самое ужасное, по номерам автомобилей были выяснены остальные персональные сведения их владельцев и выложены на националистском сайте. (ссылку приводить не буду, желающие сами найдут)
Сведения, само собой, секретные, и были выкраны из электронных систем, и вот на основе этого прецедента, предлагаю обсудить будущее, в котором такое возможно, и что можно сделать, чтобы предотвратить подобное. (только не надо совсем простых советов, в стиле, не допускать таких людей к данным, пойдем лучше путем банков, где администраторы не смогут данные расшифровать, клиенты просмотреть незамеченно, итд..)
Ведь данные в плохих руках штука опасная, и всем нам знакомая по фильмам, где агент ФБР, меняет данные в регистре преступников, и все, ты уже ничего не можешь сделать и оправдаться. (наверное, глупый пример)
Конечно, волков бояться… Но тем не менее. (да и стоит понимать, что НЕ использовать эти системы просто невозможно в нашем обществе)
В Эстонской системе электронных рецептов для безопасности была возможность просматривать данные о том, кто смотрел твою карту, с возможностью ограничивать доступ, у нас же, даже сама полиция не имеет понятия, как такое могло случится (кризис, друзья) и кто, что просматривал.
Новость на Delfi
Видео новостей с Первого канала — тут и есть ссылка для любопытных.
В Латвии из электронных систем, пользующихся популярностью есть всего несколько:
Из государственных:
- Регистр предприятий
- жителей
- автомобилистов
- Также недавно обновленный кадастровый регистр собственности.
Из частных:
- Регистр платежеспособности (о задолжностях банкам/фирмам)
- Cистема доверия (о кидалах (в основном с недвижимостью))
Так вот, сейчас на днях стало известно о том, что националисты собирали фотографии и данные об автомобилистах, использующих на своих автомобилях символику Российской Федерации (флаги, Георгиевские ленты)
И что самое ужасное, по номерам автомобилей были выяснены остальные персональные сведения их владельцев и выложены на националистском сайте. (ссылку приводить не буду, желающие сами найдут)
Сведения, само собой, секретные, и были выкраны из электронных систем, и вот на основе этого прецедента, предлагаю обсудить будущее, в котором такое возможно, и что можно сделать, чтобы предотвратить подобное. (только не надо совсем простых советов, в стиле, не допускать таких людей к данным, пойдем лучше путем банков, где администраторы не смогут данные расшифровать, клиенты просмотреть незамеченно, итд..)
Ведь данные в плохих руках штука опасная, и всем нам знакомая по фильмам, где агент ФБР, меняет данные в регистре преступников, и все, ты уже ничего не можешь сделать и оправдаться. (наверное, глупый пример)
Конечно, волков бояться… Но тем не менее. (да и стоит понимать, что НЕ использовать эти системы просто невозможно в нашем обществе)
В Эстонской системе электронных рецептов для безопасности была возможность просматривать данные о том, кто смотрел твою карту, с возможностью ограничивать доступ, у нас же, даже сама полиция не имеет понятия, как такое могло случится (кризис, друзья) и кто, что просматривал.
Новость на Delfi
Видео новостей с Первого канала — тут и есть ссылка для любопытных.
.NET → 2й подкаст Петербургской группы Alt.Net
Участники: butaji & dnesteruk Persistence в .Net-приложениях
- Роль persistence layer в приложении
- Реляционные базы данных: SQL Server/Compact Edition, Oracle, MySQL, SQLite
- Объектные базы данных: db4o, CouchDb (+ Divan), MongoDB
- Объектно-реляционные мэпперы (ORMы): NHibernate, Entity Framework, Linq2SQL, LLBLGen, Subsonic, Telerik OpenAccess; сравнение разных ORM-фреймворков (warning: сайт написан авторами DataObjects.net)
- LINQ провайдеры и LINQ-like запросы в RoR
- Должен ли разработчик быть еще и DBA?
Блог им. sanchez911 → Mysql против Sql Server – кто кого?
Рискну завести холиварную тему :)
Я думаю, чтоб все согласятся с тем, что по фукнционалу Mysql значительно проигрывает Sql Server-у. На мой взгляд, не выигрывает Mysql и по критерию бесплатности: у Sql Server есть бесплатная Express-версия, которая, в отличие от конкурента, может быть использована в коммерческих разработках без лицензионных ограничений.
Но сейчас речь не об этом. Для меня самый интересный был вопрос производительности. Тестам от производителей верить сложновато, поэтому я решил провести собственный тест.
Для этого я взял базу данных AdventureWorks и перегнал ее в Mysql (получился дамп размером около 100 Мб) с сохранением всех ключей, индексов и т.п. После чего написал тестовое приложение на .Net, которое бы гоняло одни и те же запросы по базам, причем можно варьировать количество одновременно работающих потоков. В запросы подставлялись случайные числовые и строковые значения (в условия where, order by и т.п.), чтобы они не кешировались. Никакие оптимизации не проводились ни на одном из серверов.
Ну перейдем сразу к делу :)
Простые запросы SELECT (с условиями where, order by, limit / top):
Сложные запросы SELECT (с различными join, вложенные запросы):
Пока нет запросов на вставку/удаление/обновление, нет триггеров и хранимых процедур. И пока нет исходников самой программы, дампов базы данных и т.п. Это все нужно оформлять, но если интересно – я займусь :)
Я думаю, чтоб все согласятся с тем, что по фукнционалу Mysql значительно проигрывает Sql Server-у. На мой взгляд, не выигрывает Mysql и по критерию бесплатности: у Sql Server есть бесплатная Express-версия, которая, в отличие от конкурента, может быть использована в коммерческих разработках без лицензионных ограничений.
Но сейчас речь не об этом. Для меня самый интересный был вопрос производительности. Тестам от производителей верить сложновато, поэтому я решил провести собственный тест.
Для этого я взял базу данных AdventureWorks и перегнал ее в Mysql (получился дамп размером около 100 Мб) с сохранением всех ключей, индексов и т.п. После чего написал тестовое приложение на .Net, которое бы гоняло одни и те же запросы по базам, причем можно варьировать количество одновременно работающих потоков. В запросы подставлялись случайные числовые и строковые значения (в условия where, order by и т.п.), чтобы они не кешировались. Никакие оптимизации не проводились ни на одном из серверов.
Ну перейдем сразу к делу :)
Простые запросы SELECT (с условиями where, order by, limit / top):
Сложные запросы SELECT (с различными join, вложенные запросы):
Пока нет запросов на вставку/удаление/обновление, нет триггеров и хранимых процедур. И пока нет исходников самой программы, дампов базы данных и т.п. Это все нужно оформлять, но если интересно – я займусь :)