なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル
業務でどれだけSQL力がつくのか ~SQLアンチパターンを用いて確認~ 前編
はじめに こんにちは。 GMOアドマーケティングのKONCEです。 新卒で入社し、数年経ちました。日々の業務で学ぶことは多いですが、今年度は技術の深堀りをテーマにやっていきたいと思っています。 今回は入社してDBやSQLに関しては業務内で学ぶことが多く、特別訓練をしていたわけではなかったのですが、「SQLアンチパターン」を用いて学びながら、改めて自分の現状を見つめ直していけたらと思います。 今回は学習を行う側面と自分自身のレベルについて見直していきたいので 知っていた → ○ 部分的に知っていた → △ 知らなかった → × を付けてみようと思います。 目次 SQLアンチパターンについて Ⅰ部 データベース論理設計のアンチパターン 2-1. [○]1章 ジェイウォーク（信号無視） 2-2. [×]2章 ナイーブツリー（素朴な木） 2-3. [○]3章 IDリクワイアド（とりあえずID） 2
カーソル処理は遅いことがある：データベース系SEの脳内データとインデックス：So-netブログ
先日の勉強会で話題になったので少しだけ。 カーソル処理はパフォーマンス問題の原因になります、という主張についてです。 私は勉強会などでカーソル処理は辞めた方が良い、と言います。 その理由は処理遅延が起きるからです。 その主張の根拠としているのは以下です。 ・SQLは結果セットでの処理に適した処理系であり、手続き型言語の処理に合わせたカーソル処理はRDBMSで処理するには無駄が多い（RDBMS内では1行1行処理するので、都度アプリとの通信が発生し、ターンアラウンドの時間が無駄になる） ・SQL Serverではカーソルの中間データは場合によってTEMPDBに保存され、都度呼び出される。つまりDISK IOが発生する要因となる カーソルは数百行程度の処理であればそれほどパフォーマンス問題は起きにくいと思いますが 数万行、数億行を1行1行丁寧に処理すると、1行の処理そのものは遅くなくても、処理全
10年間のプログラミングの変化といえばクラウド、型推論、リアクティブ - きしだのHatena
この10年間のプログラミングの変化、というのが流れてきたのだけど、個人的にはクラウド、型推論付き静的型、リアクティブかなぁという風に思ってます。 クラウド(とスマホ) 2008年にGoogle App Engineが出たり、最初のHadoopサミットが行われたり、ちょうど10年前に始まったとも言えるクラウドは、すでに流行ではなく常識になっています。 いまや、クラウドを考えずにシステムを組むということはないんじゃないでしょうか。 スマホもこの10年で広まり、端末にUI、データはクラウドということも当たり前になっています。 40%の視聴率をもった紅白で視聴者が同時投票するようなことも、AWSを使って危なげなく行えるようになっていますが、10年前にこのようなサービスをたった4時間だけ行うということはなかなか考えにくいもので、実現できるのも限られたベンダーだけだったと思います。けれどもいまではそれ
論理型の設定値を RDB に保存する場合の選択肢と各々のメリット・デメリット
ユーザごとに特定の機能に対して ON/OFF の設定値を持たせることはよくあると思います。 RDB にそのような設定情報を持たせる場合の選択肢として大きく次の 5 つが考えるんじゃないかと思います。 設定項目ごとにカラムを割り当てる 設定項目ごとにレコードを割り当てる（追記：アンチパターンという意見があるので最後に補足を書きました） 設定項目ごとにテーブルを割り当てる（自分は思い付かなかった） 設定項目ごとに 1 つの整数型カラムの 1 bit を割り当てる 1 つのカラムに JSON 等で全ての設定情報を持たせる データベース理論的には 1, 2, 3 以外の選択肢はない気がしますが、実用上は 4, 5 も良い選択となることがあるので、メリット・デメリットを考えて選択する必要があると思います。 そんなわけで、それぞれの選択肢に関してメリット・デメリットを自分なりに考えてみました。 考慮す
データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
ゲームエンジニアのためのデータベース設計
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails アンチパターン「RDBMS を単なるデータストアとして扱う」 / Rails Anti-pattern RDBMS is not more than datastore
MySQLテーブル設計入門