マスターテーブルと「有効期間」 - 設計者の発言
マスターテーブルには「比較的変化しないデータ」が登録されるが、Ｍ＆Ａが常態化した結果、取引先マスターあたりは頻繁に変わるようになった。社名や取引条件が変わるだけでなく、複数の取引先が１社に統合されることもある。 ここらへんは、マスターデータに「有効期間」を設けるべきかどうかの問題としてしばしば話題になる。「有効期間を含むテーブルとの参照関係」の記事でも触れたが、もう少し補足しておきたい。結論を先に言えば「ケースバイケースではあるが、それほど神経質になる必要はない」ということだ。 まず、有効期間を伴わない通常例を見よう。(1)では、すべての属性項目が主キーであるidに関数従属している。 (1)期間管理しないパターン [得意先GRP] GRP_id、グループ名、... ＋ 012 Ｍグループ ｜ └―…[得意先] 得意先id、社名、GRP_id、... 00001 Ｍ社
「有効期間」を含むテーブルとの参照関係 - 設計者の発言
一次識別子に「有効期間」が含まれることがある。そんなテーブルに対して関連を張ってゆくと正規化違反を生じてしまうケースがある。これを避けるためには「動的参照関係」の知識と、これに対応した開発基盤が必要だ。よほど単純なＤＢでない限り「動的参照関係」のデータ要件は出現するものなので、実務者としてはしっかり理解しておきたい。 まず、有効期間とキーとの関わりを整理しておこう。「商品値引テーブル」を例にした場合のモデリングパターンをいくつか挙げよう。{...}内はキー（一次識別子）を表している。 (1)開始日・終了日ともに属性 [商品] {商品ID},商品名,... ＋ 12345 全自動漬物石ＴＳ１００ ｜ └―…[商品値引] {商品値引ID},商品ID,開始日,終了日,値引率,... 000001 12345 07/01 08/31 15 000002 12345 08/01 09/30
サロゲートキーの日常性と心得之条 - 設計者の発言
「モノクロとカラーのどちらの表現を選ぶか」と訊かれて、映画監督はなんと答えるだろう。おそらく「どちらかを選べだって？愚問だね。必要に応じて使い分けるだけさ」と答えるだろう。同様に「サロゲートキーと複合主キーのどちらの技法を選ぶか」なんて訊かれても困る。どちらも必要に応じて使うだけの話で、どちらかが強制されるようなものではない。 実際のところ、複合主キーと同様、サロゲートキーも必要不可欠な技法だ。それは設計者本人さえ意識しないまま、日常的に利用されている。たとえば多くの場合、受注テーブルの主キー（一次識別子）である「受注№」は、サロゲートキーの一種だ。次のモデルで説明しよう。 (1)受注情報のモデル１ [顧客] 顧客id,顧客名 ＋ ｜ └―…[受注見出し] 受注№,顧客id,受注日,... ＋ ｜ └―∈[受注明細] 受注№,明細行番,商品id, 受注数,納期,... 受注情報は、出荷情報
渡辺式データモデリングの復習 - プログラマの思索
渡辺幸三さんのデータモデリングの手法について、復習と理解のために残す。 以下メモ書き。 間違っていたらあとで直す 【1】サロゲートキーの注意点 サロゲートキーは、トランザクションテーブルに多い。 受注番号、注文番号のように、シーケンスとして単に採番される。 しかし、実際のテーブル設計では、サロゲートキーを持つテーブルは、主キーとは異なる一意なキー項目が存在する場合がある。 たとえば、商品マスタのJANコード、従業員マスタの社会保障番号などだ。 あるいは、発注テーブルの受払Noなどもそうだ。 サロゲートキーはWebシステムではとても相性が良い。 しかし、何でもかんでもテーブルをサロゲートキーによる主キーで設計すると、業務要件をカラム間の関数従属性で表現しきれなくなる。 すると、そのような従属性はアプリ層で実装するようになり、システムが肥大化していく弱点がある。 だから、一意制約を持つキー項目
MySQL - InnoDB データファイルをテーブル単位に変更！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... MySQL でストレージエンジンに InnoDB を指定していると、データファイル・ログファイルが作成されます。 デフォルトでは、データファイル（ibdata1）はデータベースが複数あっても１つのファイルとして作成されます。 これだと、データベースが複数あったりサイズが膨大になったりすると、パフォーマンスが悪くなるだけでなく管理も煩雑になってしまいます。 設定ファイルに innodb_file_per_table を設定することで、このデータファイルをテーブル単位で管理できるようになります。 ただ、既にデータベースを InnoDB で運用している場合は、今後作成するテーブルに
MySQL - InnoDB データファイル ibdata1 の最適化！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... MySQL のストレージエンジン InnoDB は、デフォルトでは ibdata1 というファイルにデータを保存・蓄積しています。 そして、この ibdata1 ファイルは、データ領域が不足すると自動で拡張されるようになっています。（設定により初期サイズと拡張サイズは異なる） ibdata1 ファイルのサイズは、データを削除しても縮小されることはないので、ファイルサイズはメンテナンスしないと日々拡大していきます。 以下、最適化についての記録です。 0. 前提条件 対象の MySQL サーバのバージョンは 5.6.11 （インストールは「こちら」の方法で行なっている） 対象のデ
MySQL ibdataのデータサイズが肥大化した場合の対処方法。 - Qiita
はじめに MySQLでibdata1のデータサイズが肥大化していた際の対処法。 今回、とある案件でサーバの調査をしていた際にibdata1のサイズがかなり大きくなっているのに気づきました。100GBを余裕で越すほどの。 これはInnoDBのデータ領域(テーブルスペース)です。 こうなると稼働したままデータサイズを小さくするのは難しく、リストアが必要となります。 事前準備 リストア作業を行う前にデータベースを利用するサービスを停止またはメンテ表示にしてトランザクションがmysqlへ来ないようにしておきましょう。 作業 1. mysqldumpの取得 サービスを停止したら対象となるデータベースのdumpを取得します。 だいたいこういう時はデータサイズが大きいので&をつけて実行しておくと便利です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
