Sqlime is an online SQLite playground for debugging and sharing SQL snippets.
Using SQLite: Small. Fast. Reliable. Choose Any Three. (English Edition) 目次 目次 はじめに SQLiteの歴史 特徴 トランザクションがある 設定がない 様々なSQL機能が利用可能 クロスプラットの単一ファイルで管理 高速にデータにアクセスできる 大規模なデータを管理できる ソフトウェアが小さい ソフトウェアやファイルフォーマットが安定している ソースコードがPublic domainで公開されている。 ソフトウェアとしての品質が高い 使い方 公式のCLIツールを使う Pythonの公式モジュールsqlite3を使う PandasのDataFrameとSQLiteをやり取りする 参考資料 MyEnigma Supporters はじめに 世界で最も使われているOSSってなんだろうと考えた時に、 真っ先に思いつくのが
1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース
Android: SQLiteDatabaseとコンフリクトアルゴリズム
SQLiteDatabaseのINSERT/UPDATE文でコンフリクト対応する話 . はじめに SQLiteはデータのコンフリクトを解消するコンフリクトアルゴリズムをサポートしており, CREATE TABLE構文でON CONFLICT句として指定できる. INSERT, UPDATE構文では文体をより自然にするためにON CONFLICTではなくOR句として指定される. Androidでもこれを使うことができる. SQLiteDatabaseクラスを使ってINSERT or UPDATEをする際にコンフリクトアルゴリズムを指定できるメソッドがAPI Lv.8から用意されている. SQL As Understood By SQLite Android Developers - SQLiteDatabase.insertWithOnConflict Android Developers
Exclusive control Shared lock, Exclusive lock トランザクションの競合が発生すると前述の競合問題が発生する. 競合を回避してデータの一貫性を保証するためには共有リソースへのアクセスを制限するロックメカニズムを導入して排他制御を促進する. 排他制御とは, 他のトランザクションから共有リソースへのアクセスを制限(ロック)するものである. ロックはトランザクションの完了まで保持されたあと解除され, 他のトランザクションはそれまで共有リソースへアクセスすることができない. ロックは他のトランザクションのアクセスを制限するという特性から, パフォーマンスに大きく影響する. そのためロックにはいくつか形態があり, 用途によって使い分けられる. ロックの形態は大きく2つ存在する. Shared lock - 共有ロック トランザクションがデータを読み込む場合の
#はじめに Realm Advent Calendar 6日目を担当する@takkeです。 私が作成したAndroid用TwitterクライアントTwitPaneで「ツイートを保存するDB」としてRealmを採用してから4ヶ月ほど経ちました。 導入当初に Twitterクライアントの内部DBをSQLiteからRealmに移行したときのノウハウまとめ という記事を書きましたが今回はその続編としてその後の運用で得られたノウハウを書いていきます。 と言いますか・・・、 世間にはRealmの性能や便利な使い方など良い側面ばかり取り上げた記事があふれていますが僕らはもっと現実的なノウハウを求めているんです！！今回はその呼び水として「Realmが原因でクラッシュすることが多すぎたのでSQLiteに自動的に縮退する仕組みを作った」件について書きます。 Realmのバージョンは少し古くて 0.84.1 で
アニマネの内部ではアプリとサーバー間でどのようにデータを受け渡ししているかという話をしてみます。 一般的にアプリとサーバー間のデータの受け渡しだとJSONやXML、YAMLなどが多いと思います。 ここにSQLiteという選択肢を入れると色々幸せになれるという話です。 もはや何で今までJSONという固定観念が捨てられなかったのかというぐらい、個人的にはコロンブスの卵でした。 あまり事例はなさそうなので、ここで紹介してみます。 アニマネでの問題点 アニメアプリのアニマネでは主にアニメの番組表やニュースをサーバーから受け取って表示しています。 都道府県にもよりますが、一つの都道府県の1週間分の番組表（アニメだけ）をJSONにすると大体750KBぐらいになるんですね。 これを開発初期ではMessagePackに置き換えてました。 話の本筋とは関係ないですが、JSONよりはMessagePackの方
研究でSQLiteを使ってる。ファイル1つでポータブル、受け渡しも楽だしバージョン管理もできるし割りと気に入ってる。 日付のデータを大量に扱うのが遅くて困ったので速くする方法を調べた。ちゃんとインデックスが効くようにしたい。 SQLite3 には、SQL99 の DATE や DATETIME に対応する日時を表す型は存在しません。SQLite3 で日時を扱う場合、Date And Time Functions で説明されている日付処理関数を使用し、TEXT 型や NUMERIC 型の列に日付データを作成します。 http://www.tamandua-webtools.net/sqlite3-date.html TEXTを使う場合では、YYYY-MM-DD HH:MM:SSみたいな書式の文字列を日付とみなす。 NUMERIC(INTEGER or REAL)はよくあるUnixエポックから
はじめに この記事は「Android Advent Calendar 2014」の5日目の記事です。 追記(2015/12/19) 2015年版を書きました。どうぞご覧下さいませ。 天下一「AndroidのORM」武道会（2015年版） - Qiita tl;dr 3行でまとめ へ移動↓ AndroidのORM事情 スマートフォンアプリでは、ネットワークから取得したデータの保持や、ユーザーが入力したデータの保持、その他いろいろなデータの管理にSQLiteデータベースを使用することが多いと思われます。 これらはAndroidの標準APIで操作できますが ―一度やってみればわかりますが― 非常にめんどくさく、思わず険しい顔になってしまいます。 そんなAndroidのSQLite操作を楽に行うため(そして実装時間節約のため)、O/Rマッパー(ORM)を導入するのは良い判断だと思います。 ところが
SQLiteは追記型という形式でデータベースファイルを管理していて、データを書き込むたびにゴミデータが貯まっていきます。 なので、定期的にVACUUMをしてゴミデータを整理するのが普通です。 しかしAndroidでSQLiteを使う場合はVACUUMを実行しなくてもデータベースが肥大し続けることはありません。 これは、AndroidがSQLiteのAuto Vacuumを有効にしてデータベースを作成するためです。 以下はAndroidが作成したデータベースと、SQLiteデフォルトのデータベースのauto_vacuumの設定値を比較したものです。 auto_vacuum Pragmaが有効になっていることがわかります。 PRAGMA Android SQLiteデフォルト auto_vacuum 1 0 auto_vacuumが1に設定されていると、SQLiteはトランザクションのコミット
mysqlviz Render a graphical representation of a MySQL or SQLite database from a mysqldump or sqlite3 .dump file. News 2013/09 Version 1.0 released: Uses /usr/bin/env/php in shebang line to improve portability Fixes new PHP versions' now-deprecated split() with explode() Silences warnings on modern PHP default configurations related to array indices handling ~2009 Version 0.3 released: Now with sql
FileBackupHelperはCotext.getFilesDir()配下のファイルを対象にしているため、SQLiteのデータベースファイルをバックアップするには、ダーティな方法を使わなければならない。 FileBackupHelperがバックアップ対象のファイルをフルパスに解決するコードは以下のようになっていて、Context.getFilesDir()で取得したディレクトリを親ディレクトリとして、コンストラクタに指定したファイル名(files[i])を連結する。 File base = mContext.getFilesDir(); ... fullPaths[i] = (new File(base, files[i])).getAbsolutePath(); ... performBackup_checked(oldState, data, newState, fullPaths
Flywayとは FlywayとはDBマイグレーションフレームワークです。 複数人でのアプリケーション開発時のDBマイグレーション作業を素早く手軽に行うことができます。 MavenやAnt、APIやコマンドラインツール形式で提供されており、柔軟に対応することができます。 環境構築方法 今回使用した動作環境は以下のとおりです。 OS : MacOS X 10.7.4 MySQL : 5.5.15 flywayを使ってみよう 環境設定 flywayはMavenやAPIからも使用できますが、今回はCommand-line Toolを使ってみましょう。 ここからCommand-line Toolをダウンロードして解凍しておきましょう。 次にテストで使用するデータベースを用意します。今回はMySQLを使用しました。 mysqlを起動し、コンソールからデータベースを作成しておきましょう。 mysql>
実機のSQLiteにアクセス 先日、Androidアプリの動作確認を実機(Galaxy Nexus)で行いました。 昔は問題なくadb shellで中にはいってsqlite3コマンドで確認できた気がしてたんですが、 DBファイルがある場所へ移動してファイルを確認しようとしたらpermission deniedだし、 そもそもsqlite3コマンド自体が使えないという状況でした。 rootとってsqliteを移植してる人もいましたが、今回はデータベースファイルの中身を確認するのが目的だったので、 データベースをPCにもってくる方法についての備忘録的tipsです。 もっとちゃんとした回避策があるような気がしなくもないですが。誰か知ってたら教えてください。 環境 今回使用した動作環境は以下のとおりです。 OS : MacOS X 10.7.4 実機 : Galaxy Nexus Android
ContentProvider アクセスには CursorLoader を使おう Android アプリでデータベースを扱いたい場合は SQLite を使用しますが、他のアプリで使用している データベースへのアクセスには ContentProvider を使用して行います。 この ContentProvider に非同期でアクセスするための CursorLoader が Android 3.0 より導入されました (Support Package にも互換用クラスがあるので Android 1.6 から使用可能) 。今回はこの CursorLoader を使って簡単な電話帳一覧を作ってみたいと思います！今回も Support Package を使う場合の実装方法を解説します。 CursorLoader の使いかた CursorLoader は AsyncTaskLoader のサブクラスで
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
Android:SQLiteのロックとTransaction Immediate/Exclusive
！この記事は古くなっています. 更新版は下記をご覧ください.！ Android: SQLite3 LockとTransaction Immediate/Exclusive http://yuki312.blogspot.jp/2014/10/android-sqlite3-locktransaction.html SQLiteのロック機構と、Transactionで使用できるロック２種の選択基準についての考察。 ●SQLiteのロック SQLiteのロック単位は"データベース単位"。 このため、ロックを１つ取得すると同データベース上にある全てのテーブルに影響がある。 Oracle等の巨大なDBMSでは"行ロック"なんてものがあったりして細かくロックを制御できるが、軽量なSQLiteは"データベース単位"でのロックのみサポートしている。 そのため、長い時間ロックし続けると他テーブルになかなか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
