こんにちは。
シナジーデザイン / システム担当のNです。
今回のブログは、プログラミングの中身の内容が主になるので、今後入社してくるプログラマー向けに書こうと思います。
システム案件
私は先月、システム案件の作業を主に行っていました。
ベースはありながらも、仕様作成、テーブル構造、ファイル構造、UI、UXなど、最初の段階から携わりました。
正直、１つのシステムを作ること自体が初めてだったので、かなり不安がありました。
まず、何から考えたらいいのかもわからない状態、
そしてこれが必要だとわかり、いざ作り始めても途中でこれじゃダメだとわかったり。
それは適切に制限をかけられてなかったことが原因の１つとしてあります。
適切に制限をかけるとは
例えば、保存したいデータが決まっている場合のデータベースのテーブル構造を考えるとします。
テーブルのカラムを作るときに必要な情報には以下のようなものがあります。
「名前」「型」「長さ」「デフォルト値」「NULLを許容するか否か」
話が長くなってくるので今回は「デフォルト値」「NULLを許容するか否か」について書こうと思います。
delete_flagという名前のカラムを作ったとします。
名前の通りflagとついているので０(false)か１(true)しかデータとして持ってはいけません。（持とうと思ったらなんだって持つことはできますが・・・）
この名前のカラム名に会社名やら担当者名が入ることは言語道断です。
しかしそれはわかっていてもカラムのデフォルト値に「NULL」を設定すると簡単に破綻してしまいます。
０か１しかデータとして持ってはいけないのに、ここに第３の値「NULL」が登場してきます。
このNULLの何が厄介かというと、プログラム側で判定の条件が増えてしまうのです。
「もし値が１ならこの処理をしてほしい」
「もし値が０ならこの処理をしてほしい」
という条件に、
「もし値がNULLならこの処理をしてほしい」
「もし値が０、またはNULLならこの処理をしてほしい」
が追加されます。
本来、YESかNOで判断できるものに
「基本NOだけど、これならいいよ」
という曖昧なものが入り込んでしまいます。
プログラムで曖昧なものはバグの元です。
自分で把握しているつもりでも、コード量が増えていくと制御できなくなります。
毎回プログラム側で判定するのも大変です。
SQLの結果を受け取るホスト言語によって、NULLの判定方法に違いがあったりもします。
なので、この場合はデフォルトに０を設定してレコードが作られたときに値の指定がない場合は必ず０が入るようにするべきです。
このように、１例ではありますが、システムを作ってみて最初に適切に制限をかけることはすごく重要なのだと感じることができました。
次回に続きます
テーブル構造の１例だけで長くなってしまったので次回のブログに続きを書きます。
書きながらプログラミングは奥が深いなと改めて感じました。
最後までお読みいただき、ありがとうございました。
