t_wの輪郭

Feedlyでフォローするボタン
設計データベース設計テーブル
T字型ER手法あれあれあれ『繰り返しイベントを扱うデータ構造』『設計者の発言 業務システム開発とデータモデリングに関する語り』『履歴データテーブルとの向き合い方_PHPerKaigi2024』あれあれ『「LAPRASのDB設計についてそーだいさんに相談してみた」イベントレポート』EAVCTICCISTI『実践データベース設計 - Speaker Deck』『ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳』あれ『Poolにおける残高管理の設計 - カンム テックブログ』ドキュメントにテーブル設計手法を応用するあれ『基本のキ「簿記のデータモデル」を学ぼう - 設計者の発言』

あれ

2025/4/30 0:21:00

家計簿つけようかしら。

まずデータベースのテーブルを設計します。

あれ

2025/1/24 11:12:00

やりたいこと

テーブル定義[1]を書く（ymlか何かで）
[1]からDDLを生成する
[1]からER図を生成する

CTI

2024/6/29 21:57:00

Class Table Inheritance
クラステーブル継承

CCI

2024/6/29 21:56:00

Concrete Class Inheritance
具象クラス継承

STI

2024/6/29 21:56:00

Single Table Inheritance
単一テーブル継承

EAV

2024/6/29 21:53:00

実体-属性-値モデル

あれ

2024/5/24 23:35:00

書きかけ

オブジェクト指向的な発想では、データベースにpersonというテーブルがあったときに、personテーブルのカラムとしてnameを持つことになる。そして、ソフトウェア開発の現場ではしばしば「personはnameを持つ」と呼ぶ。したがって「nameはpersonに属する」と認知されている。

しかし、発想を逆転すると、「あるpersonの個体（つまりレコード）は、あるnameの個体の集合に属する」という見方ができる。具体的かつ日本語にすれば、「personの個体であるところの田中さんは、nameの個体であるところの"田中"という集合に属している」。

上記をテーブルにするならば、personテーブル、nameテーブル、


ソフトウェア開発ではしばしば、「テーブル間の関係が1対1であると思われていたが、実は1対多だった」あるいは、「実は多対多だった」ということが発生する。実際、多くのプログラマーの認知に反して、人と名前の関係は1対1ではない。

あれ

2024/1/31 22:46:00

テーブル設計技法のイベントソーシングを試すぞ！！

あれ

2022/3/26 14:06:00

　テーブル設計がつらすぎる。DBの経験が薄い＆DBから長らく離れていた せいだろう。プログラムだったら感覚でなんとなくなんかいい感じにできてしまうが、経験のないやつはどうしようもない。
　PlantUMLでER図を書いて、壁打ちしたほうがよさそうだ。設計資料も残るのでその意味でも利点がある。

あれ

2021/8/22 13:16:00

だいぶめんどくさくなってきたな。乗り換えるとなると、DBのテーブル設計もやり直さないといけない。いっそ作り直したほうが楽ではないかと思えてくる。

部分的にjsStoreに置き換えるとかでもいいのかもしれない。