原文(投稿日：2009/3/15)へのリンク ACID特性はデータベース論の基礎の一つです。ACIDではデータベースの信頼性を保つために必要とされる4つの属性を定義しています。原子性(Atomicity)、一貫性(Consistency)、分離性(Isolation)、そして永続性(Durability)です。4つの属性はいずれも重要ですが、とりわけ分離性については最も柔軟に解釈されています。ほとんどのデータベースがいくつかの分離レベルを選択できるようにしていますし、最近は多くのライブラリがより極め細やかな分離レベルを作成するレイヤを追加しています。このように広範囲の分離レベルが存在している主な原因は、緩い分離レベルによって拡張性や性能が数桁のオーダーで異なることにつながるからである。 シリアライズ可能というのは最も古典的で高い分離レベルであり、一般的に使うことが出来るもので、多くの人がそ

2015-10-08(木)に行われた理論から学ぶデータベース実装入門Nightで行ったLightning Talkのスライドです。Read less

いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。

SQLの苦手を克服する本 https://www.amazon.co.jp/gp/product/4297107171 ブログで書いている内容を、もっと分かりやすくしたものです。 例えば、以下の記事の内容も、分かりやすく解説しています。 「SQLを文字列連結して作る必要はない」 sikushima.hatenablog.com 私はどうしても、「自分が理解している範囲をエンジニアなら理解しているだろう」という想いで文章を書いてしまいます。 しかし、それでは難解で理解できないエンジニアが多いということで、開米瑞浩さんに第三者にもわかりやすくリライトしていただいています。 ideacraft.jp 是非、ご購入いただければ幸いです。

はじめに CASE式は、SQL-92で標準に取り入れられました。比較的新しい道具であるためか、便利なわりにその真価があまり知られておらず、利用されていなかったり、CASE式の簡略版であるDECODE（Oracle）、IF（MySQL）などの関数で代用されていたりします。 CASE式を活用すると、SQLでできることの幅がぐっと広がり、書き方もスマートになります。しかも、実装非依存の技術なのでコードの汎用性も高まります。特にDECODE関数を使っているOracleユーザーには、ぜひCASE式への乗り換えをお薦めします。 前回『CASE式のススメ（前編）』では、CASE式の文法とその応用方法について解説しました。今回は引き続き、CASE式のより高度な応用方法について解説します。 必要な環境 次のいずれかのデータベース（MS Accessは対象外）。 Oracle（9i以降） SQL Server

メモ書き SQLでWith句を2つ以上書く場合は下記のように書く ポイントは、2つ目以降のWith句は,でつなぎ、先頭にWithをつけないこと with句を２つ以上書くサンプル declare @FromDate varchar(7) = '2017/03'; declare @ToDate varchar(7) = '2017/04'; declare @FromDate2 varchar(7) = '2017/03'; declare @ToDate2 varchar(7) = '2017/04'; with NendoMonth as ( select cast( @FromDate + '/01' as datetime ) as monthDate union all select dateadd( MONTH, 1, monthDate ) from NendoMonth wh

話を始める前にまずは簡単によく使うSQLの結合公文を復習していきます。 - INNER JOIN (内部結合) - LEFT OUTER JOIN (左外部結合) - RIGHT OUTER JOIN (右外部結合) - FULL OUTER JOIN (完全外部結合) このままの形式で書くことはあまりありません。基本的に - INNER JOIN ⇒ JOIN - LEFT OUTER JOIN ⇒ LEFT JOIN - RIGHT OUTER JOIN ⇒ RIGHT JOIN といった省略形で書くことが多いです。 LEFT JOINとRIGHT JOINがなんなのか最初に掴むまで苦労しましたが、いくつか手で書いてみるとわかります。 ここに雑な例を載せておきます。 mysql> SELECT * FROM photobook; +------+--------------------

select * from ... と書いてはダメ、たとえ全列取得する場合でも select a, b, c, d from ... と書くのが常識、という話をずいぶん前に聞いたことがあって、意味がわからないので人力検索に投げてみた。 いただいた回答を整理しておく。 テーブル内の一部の列を参照したい場合 例えばクライアント側では1列しか見ないのにワイルドカードで全列取得することには、パフォーマンス上の問題がある。 select * from ... でも select a from ... でもディスクI/Oのコストは基本的に変わらないが*1、それ以外のところに問題がある。 ネットワークの問題。DBサーバからクライアントに転送するデータが無駄に大きくなる メモリの問題。DBMSのデータキャッシュやOSのファイルキャッシュが無駄遣いされる テーブルの全ての列を参照したい場合 全列取得したい場

この記事は「Thoughts on Rich Harris’ “Metaphysics and JavaScript”」の日本語訳です。Svelteのコーディングスタイルや記事として言及している講演のスライドも併せて参照しなければ理解しづらい内容です。 公開にあたっては著者のJim Nielsen氏に許諾をいただいています。 要旨としては、ユーザーにとってSvelteは実際のDOMとのメンタルモデルのギャップが少なく感じられるデザインであって、結果的に、Reactより理解しやすいプログラミングモデルになっているという話です。 Svelteの考案者であるRich Harris氏は、Reactのプログラミングの側面を批判する「形而上学とJavaScript」というタイトルの最近の講演のスライドを共有しました。この講演には非常に説得力があり、Reactを利用した私の経験にも当てはまるとわかりまし

BigQueryで遊び初めて、早5ヶ月。色んな単語と出会いました。 スロット, 分散ストレージ, シャッフル, 分割テーブル, クラスタ化テーブル・・・ 特に分割テーブル, クラスタ化テーブルはBigQueryのベストプラクティスとして紹介されます。 でも、BQ初心者には何がいいんだかさっぱりわからんのです。 ドキュメントを読んでもあまりピンとこないのです。 だったら！！実際に検証して、 分割テーブルやクラスタ化テーブルがどんだけ意味があるのか？どんだけすげーのか？ 確かめたいと思い、今回記事にしようと思いました。 はじめに この記事は，NTTドコモサービスイノベーション部AdventCalendar2019の12日目の記事になります。 12日目のこの記事では，GoogleCloudPlatformのDWHサービスであるBigQueryの分割テーブル(partitioned table),

出典 H3: Uber’s Hexagonal Hierarchical Spatial Index (2018/06/27) 筆者 Isaac Brodsky Isaac Brodsky is a software engineer on Uber’s Marketplace Intelligence team. Uberとは Uberホームページ 世界を席巻しつつある白タクサービス、宅配のUber Eats、オンデマンドフライトのUberAIRなどで生活を変えようとしている。 日本進出はソフトバンクがサポート 参考：ソフトバンク、ウーバーへの出資完了 H3とは 大小様々な六角形をグリッドとする新しいインデックスシステム（座標システム） （「大小様々な六角形」、「階層的な六角形」の説明は後ほど） 本文 ※意訳している部分があるので、引用元も参照ください。 なぜH3 地図などの空間データセ

事実は小説より奇なり。誰も恨まない生き方をするに至った過程をnoteにまとめ、たった1人でも役立てば良いと考え、ナレッジとして残すことにした。 経営は社長に責任がある。これは間違いない。起業家は出資者を恨むことをしない方が幸せになると思う。これもたぶん間違いない。厳密には違うけれども僕が心がけていることだ。 そんな僕が、金商法違反を平気で行うベンチャーキャピタル（VC）から個人破産申立をされた末に4,000万円支払った話をしようと思う。 しかし今でもVCを恨んでいない。そんな能天気な自分が明日を創ると信じている。起業家なら暴風雨でも前を向いて進みたいものだ。 さて、この話では普通は表に出てこないような失敗談や注意すべきポイントが多数出てくる。これから起業してエクイティによるファイナンスを検討している人にとって参考事例になることを願う。 未だに存在する昔ながらのベンチャーキャピタル起業した一

今月の日記は「NEW VINTAGE｜Sweater in the Memory 2019」撮影の舞台裏です。WEBで公開中のビジュアルとあわせてお楽しみください。　待ち合わせ場所に選んだのは「新宿の目」だった。真っ先にやってきたのはシンガーソングライターのカネコアヤノさんで、スニーカーの白さが際立って見えた。聞けば、一番ぼろぼろの靴を履いてきて、新しいスニーカーを買ってきたのだという。古い靴はお店に引き取ってもらって、買ったばかりのスニーカーに履き替えてきたのだ、と。彼女の「とがる」という曲の歌詞が、ふいに思い浮かんだ。 今日は新作のアランニットのビジュアル撮影の日だ。モデルを務めるのはカネコアヤノさんで、撮影するのは木村和平さんである。 「私は和平君のことを“かずへりん”って呼んでるんですけど、彼が10代の頃すごくファッションが好きで、原宿によくいた時のあだ名です。私もまだ学生だった頃

タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま

ユッティンゲン (ドイツ語: Uettingen) はドイツ連邦共和国バイエルン州ウンターフランケン地方のヴュルツブルク郡の町村（以下、本項では便宜上「町」と記述する）であり、ヘルムシュタット行政共同体を構成する自治体の一つである。 地理[編集] ユッティンゲンはアールバッハ川沿い、ヴュルツブルク郡内の連邦道B8号線沿いに位置する。 隣接する市町村[編集] レムリンゲン グロイセンハイム ホルツキルヒェン ヴァルトビュッテルブルン ヘルムシュタット 自治体の構成[編集] この町は、公式にはユッティンゲン集落単独で構成される[2]。 歴史[編集] 線帯文土器文化の時代の陶片の他、ユッティンゲンでは青銅器時代の手斧も発掘されている。300年から400年頃に "ûot inga" の定住が始まった。この綴り方が、村の名前がアラマン語起源であることを明確に証明している。 772年1月20日にユッテ