GoでDBアクセスする為のサンプルコードを探すとどこもこんな感じ
func main() { # dbコネクション(pool)を取得 pool, err = sql.Open("driver-name", *dsn) if err != nil { // This will not be a connection error, but a DSN parse error or // another initialization error. log.Fatal("unable to use data source name", err) } defer pool.Close() # poolを使ってDBアクセスするコード ...... }
Openしたコネクションはアプリ終了時にdefer によってClose()処理されて終わる。理解した。
すべてmain()に処理があったり、数個の関数で構成されているアプリケーションだったら上記で良いけど、 クリーンアーキテクチャ的なレイヤー構造を持ったアプリケーションだったらどうすれば良いのか悩んだ。
続きを読む「このアプリケーションのこの機能は【年月日】までしか意識しない。【時分秒】はデータとして不要なのでテーブルにはdate型で【年月日】だけ持たせれば良い。」
と言われた事があったが例えアプリケーションにとって不要でもDBテーブルにはdatetimeとかtimestampで【時分秒】まで保持しておくべきだと思ったので書く。
アプリケーションを意識しまくったテーブル設計はアプリケーション要件に依存してしまう。
だからアプリケーション要件が変わるとテーブル設計を変更しないといけなくなる。
この時、既存データとの整合性をとる必要性まで出てきて大変になる。
システムのDBには様々なテーブルが定義されている。
色々作業していると「扱いやすいテーブル」「扱いづらいテーブル」がある事に気がつく。
なんとなく見えてきたパターンについて書いてみる。
※もしかしたら当たり前の知識なのかもしれないが、自分の観測範囲ではあまり話題にならないし、前提知識として認識されているようには感じていない。もし体系化されたわかりやすいものがあるなら知りたい。
参考）
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)
