Python: ERAlchemy を使って ER 図を描く - CUBE SUGAR CONTAINER
今回は ERAlchemy という ER 図を描くツールを使ってみる。 このツールは erd という Haskell で書かれた同様のツールにインスパイアされて作られたものらしい。 ただ、機能的にできることは ERAlchemy の方が多いみたいだ。 ERAlchemy が提供する基本的な機能は次の通り。 ER フォーマットのテキストファイルから ER 図を生成する SQLAlchemy 経由で既存のデータベースから ER 図を生成する 後者の既存データベースから ER 図を生成するところなんかは、これまでだと MySQL Workbench を使ったりしてた。 ただ、このやり方だと文字通り MySQL でしか使えないのに対して ERAlchemy はそれ以外のデータベースにも対応している。 今回も試しに SQLite3 のデータベースから ER 図を生成してみている。 ただ、この機能が出
Gay marriage: the database engineering perspective @ Things Of Interest
I have never seen a paper talking about gay marriage that was entertaining, doesn't matter if you're for or against it, still an entertaining read, now THAT's how articles about current issues should be written! That was pretty cool. Things like this is what keeps me coming back. This and your fiction. As to the "ban all marriage," I've thought similarly recently. It occurred to me that the whole
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Cassandraのデータ設計で注意していること』
