漢字字体規範史データセット
漢字字体規範史データセットの概要 このサイトは、「漢字字体規範史データベース（Hanzi Normative Glyphs）」（公開期間：2005-2015年）の前身である「石塚漢字字体資料」の情報カードの画像、漢字字形の切り抜き画像、及びメタデータを「漢字字体規範史データセット」と称して公開するリポジトリです。 「石塚漢字字体資料」は、各時代・各地域（国）には漢字字体の標準が存在し、その標準が変遷することを実証するため、北海道大学名誉教授石塚晴通氏が在職中の国語学演習等で作成したものです。「石塚漢字字体資料」は、情報カードで整理され、2005年9月の時点で、漢籍・仏典・国書等の典籍67資料、総用例数約40万字に達した資料群です。 「石塚漢字字体資料」は、情報カードの劣化による保存と、学界へのデータ提供のため、2000年頃から北海道大学文学部言語情報学講座有志によって、電子化が着手されまし
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。
Scheman - r7km/s
Schemanという、Ruby製のSQLパーサをつくった。 例 文章で説明するより見たほうが早いだろうということで、例を用意した。 require "scheman" require "yaml" parser = Scheman::Parsers::Mysql.new schema = parser.parse(<<SQL) CREATE TABLE `users` ( `id` INTEGER(11) NOT NULL PRIMARY KEY AUTO INCREMENT, `name` VARCHAR(255) NOT NULL ); SQL puts schema.to_hash.to_yaml 構文解析結果はHash, Array, Symbol, Stringの組合せで表現される (※可読性のためにYAML形式で表示した) --- - :create_table: :name:
各種DBのMac用GUIクライアント - komagataのブログ
内部ツール（僕らでいえば256interns.comとか）は管理画面作らずGUIアプリで変更とか結構便利です。とはいえ、railsなどのアプリ側のみでvalidationしてると不整合が起きるので要注意。これ前提で制約追加するのもいいかも？ Sequel Pro MySQLのGUIクライアント。これを教えてもらって訝しげに使ってみたんですが、今風のMacの使い勝手で使えるのがすごく気に入っちゃいました。 SSL経由やsshで入ったサーバー踏み台にしての接続も一発できて便利。 PG Commander PostgreSQLのGUIクライアント。Sequel Proに比べると使い勝手は良くないけど、HerokuのDBに接続できる！これがデカイ。 接続先のブクマを５個以上保存しておくにはLisenceを買う必要があります。Herokuを多用するから５個あっという間に超えちゃうので買いました。 B
FacebookやGoogle、「WebScaleSQL」をオープンソースで公開
オープンソースデータベース「MySQL」を大規模システムで利用しているFacebook、Google、Twitter、LinkedInが直面する共通の問題を解決する目的で開発中のブランチ「WebScaleSQL」をGitHubで公開した。 米Facebookは3月27日（現地時間）、米Google、米Twitter、米LinkedInと協力し、オープンソースのデータベース「MySQL」のブランチ「WebScaleSQL」をGitHubで公開したと発表した。ライセンスはGNU General Public License Ver.2。 WebScaleSQLは、MySQLを大規模なシステムで使う4社が直面する共通の問題を解決する目的で共同開発したデータベースで、MySQLに大規模な環境への導入に特化した機能を追加したものという。 関連記事 Facebook、新プログラミング言語「Hack」を
Database Encryption - r7kamura per second
データベースの暗号化界隈の話を調べたのでQ&A形式でまとめた。 なぜ暗号化を行うのか？ 一般的には、以下の様な情報の漏洩を防ぐため。 個人が識別できる情報 個人の行動履歴 財務情報 知的財産 財産 その他開示されていない情報 最近日本で大きな情報漏洩被害にあった企業例は？ Sony (PlayStation Network) Yahoo! Japan LINE 2ch @PAGES データベースの暗号化におけるベストプラクティスは？ StackOverflow等の意見を集めた限り、この辺を全部やるというのがベストプラクティスという雰囲気。 通信データの暗号化: SSL 格納データの暗号化: FDE + TDE (後述) 格納データの暗号化機能を提供しているサービスの例は？ Amazon RDS for Oracle Amazon RDS for SQL Server Amazon S3 G
Git: the NoSQL Database
Check out the video for this talk: https://vimeo.com/56645405 We all know that Git is amazing for storing code. It is fast, reliable, flexible, and it keeps our project history nuzzled safely in its object database while we sleep soundly at night. But what about storing more than code? Why not data? Much flexibility is gained by ditching traditional databases, but at what cost?
MimicDB
>>> c = S3Connection(KEY, SECRET) >>> bucket = c.get_bucket('bucket_name') >>> start = time.time() >>> bucket.get_all_keys() >>> print time.time() - start 0.425064992905 >>> c = S3Connection(KEY, SECRET) >>> bucket = c.get_bucket('bucket_name') >>> start = time.time() >>> bucket.get_all_keys() >>> print time.time() - start 0.000198841094971 Works with Python and Boto MimicDB wraps every S3 API cal
長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
HerokuでDBのデータをバックアップする - アインシュタインの電話番号
HerokuアプリのDBをバックアップするにはpgbackupsというアドオンを利用する。昨日書いた方法との主な違いは、今回のはHerokuのサーバー上にバックアップされることと、フォーマットの変換はできないこと、あたりかな。バックアップ処理を自動化する場合は今回の方法が良いみたい。 アドオン追加 まず、herokuコマンドが使えるgemのherokuを最新の状態にする。 $ gem update heroku 次に、対象のHerokuアプリにpgbackupsアドオンを追加する。Basicタイプは無料。 $ heroku addons:add pgbackups:basic --app heroku-hello-world これで準備完了。 Heroku(Amazon S3)上にバックアップするには以下のようにコマンドを実行する。 $ heroku pgbackups:capture -
heroku で利用中の DB データサイズ - Qiita
を取得する方法が知りたいのだけれど、heroku info コマンドでは欲しい値が得られない。heroku が提供するデータベースの無料領域は <del> 5MB というあまりにも貧弱な容量なので、このままでは安心して遊べない。</del> 現在の PostgreSQL : Dev Plan では "10,000 row limit" とのこと。 そこで見つけたエントリ herokuでのWebアプリ開発と運用（その4：データサイズ肥大化の対処） heroku run console 後に下記を実行して ( 実際には一行 ) ActiveRecord::Base.connection.select_all( "SELECT relname, relkind, to_char(reltuples, '999,999,999') as rows, to_char(pg_relation_size
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
『Cassandraのデータ設計で注意していること』
A New Concept of Consistency in Distributed Database and Implementation in Riak
Devsの常識、DBAは非常識
MySQL Index勉強会外部公開用