[Go言語] コンストラクタの書き方

Go言語のコンストラクタは以下のように書くことが推奨されています。

http://play.golang.org/p/oM5C26l8iw

package main

import "fmt"

type Person struct {
    Name string
    Age int
}

func NewPerson (name string, age int) *Person {
    if age < 0 {
        return nil
    }
    p := new(Person)
    p.Name = name
    p.Age = age
    return p
}

func main() {
    taro := NewPerson("Taro", 26)
    fmt.Printf("name: %s age: %d", taro.Name, taro.Age)
}

NewPersonは構造体の初期化を使って以下のように記述することもできます。

func NewPerson (name string, age int) *Person {
    if age < 0 {
        return nil
    }
    p := Person{name, age}
    return &p
}

Cに慣れた人にしてみるとローカル変数のポインタを返すことに違和感があるかもしれませんが、メモリ領域は呼ぶ度に新たに確保されます。

  • Effective Go – Constructors and composite literals
    http://golang.org/doc/effective_go.html#composite_literals

データベースで1:1のリレーションシップはいつ使うのか

ちょっと気になって調べたところ、Stackoverflowに質問が。

Is there ever a time where using a database 1:1 relationship makes sense?

ベストアンサーのコメントを見ると、

A 1:1 relationship typically indicates that you have partitioned a
larger entity for some reason. Often it is because of performance
reasons in the physical schema, but it can happen in the logic side as
well if a large chunk of the data is expected to be “unknown” at the
same time (in which case you have a 1:0 or 1:1, but no more).

訳)
1:1のリレーションシップは一般に大きな実体をなんらの理由で分割したことを示している。しばしばそれは物理スキーマのパフォーマンスが原因であるが、大きなデータの固まりが同時には”未定”になるべき場合はロジックの側でも起こりうる。(その場合1:0か1:1以外にはならない)

例も書いてありますが、まあ拾い読みしていくと以下のような感じかなと。

  • パフォーマンス
    • 行ロック
  • DB容量
    • BLOB
    • ごく一部のレコードしかフィールドを持たない
  • セキュリティ

一つのオブジェクトを分割して保存していることには変わりないですが、特定のカラムが頻繁に更新されて、多くがNULLになる場合には考えてみてもいいかもしれません。