データベースを作りたい。 でも、色々な、留意点がありますね。
例えば、初期状態は問題が無くても、運用あるいはデータ蓄積に応じて、思い掛けないものが放り込まれたりします。
勿論、例外処理は重要な着目点ですが、
入力された新規データが想像の域を超える場合があります。 [つぶやき]
ちゃんと設計されたデータベースシステムとフロントエンドの場合は、最初から、その辺りを工夫して、設計されますから、
問題が生じる可能性は少ないでしょう。
しかし、個人用のちょこちょこっとしたつくりのデータベースの場合、
長い年月と共に蓄積されるデータこそが命です。
時間が経てば、当初の設計思想など忘れ、無理やりデータベース構造に合わせたデータを放り込む場合があります。
特に、データベース構造が、データの種類を考慮せず、文字型で構成されている場合など、要注意です。
例えば、論理型の列を、、文字列型で設けたとしましょう。 無論、お勧めのデータ型は論理型ですが ... 。
判別し易さに力点を置き、○×でデータ入力したとします。
この入力が、リストボックスやコンボボックスからの選択方式なら、いいのですが ... 。
手入力では、○ がいつも ○ とは限りません。
えっ、どう言う事って？
○ (U+25CB) も、◯ (U+25EF) も 〇 (U+3007) も ⃝ (U+20DD) も、丸 ○ ですから。
表示にお使いのフォントによっては、表示出来なかったり、形状が全く異なる場合もありますね。
逆に、見分けが着き難い場合もあります。
こんな時には、丸印に幾つかの文字が混在してしまいます。
表示している分には見た目の問題だけですが、 検索をする（フィルターを掛ける）と、結果が正確ではなくなってしまいます。
例えば、200 個ある筈のデータを検索すると 120 個しか見付けられない とか。
あるいは、○×ではなく、△が必要となるかも知れません。
更に、◎○△×無視、なんて。 う～ん、当初の設計ミスですね、これじゃぁ。
短文の様な 文字列は、更に悩ましいです。
例えば、説明文や詳細や備考の列。
これを検索すると、正確に表現が揃っていなければ、部分一致でも拾い上げられません。
例えば、ディテール と デテール とか。 双方をヒットするには、論理和（OR） で繋げなければなりません。
例えば、人名： 斉藤さん 。 本当は 齋藤さん でも 斉藤さん と書く時もある とすれば ... 。
名前の列では、ID 等で留意するでしょうが、文字列欄（説明文）の中で登場すれば、混乱の可能性 大。
同じ意味でも、違う表現があります。 あるいは、別名。
一番良いもの と言う表現の語句で、最高 とか、至高 とか、最善 とか、最良 とか、 ... 、 語句は違っても同じ意味。
鉛筆 と ペンシル と えんぴつ は、同じものですが、語句は違います。 ニュアンスが違うのって、誰、そんな危ない発言。.
数限りない表現を意味まで考えて検索（フィルター掛け）するのは容易ではありません。
勿論、頻出するのが予想される語句に対して、類義語テーブルを用意して、論理和で検索させる方法もありますが、
何と言ってもお手頃なのは、元データの表現を統一するのが、一番容易ですから。
幾ら蓄積されていても、利用範囲が狭かったり 応用の利かない データ では、 それこそ、宝の持ち腐れですもの。
ルールを決めて運用すればいいのでしょうが、 所詮、人のやる事。
無視したり、守らなかったり、うっかりミスする事 だって。
そして、 検索して見ると、 後の祭り。
ひとりで入力していれば、まだしも、 複数になれば、個人的な癖がデータに入り込みます。
ましてや、他人さまのお作りになった表やデータを流用して、データベースの叩き台にする場合には尚更です。
後々の検索を前提にデータ入力するのが望ましいのですが、
先に挙げた欄の様に自由度が高い短文形式の文字列の場合、その語句の選択は難しいですね。
運用していて、あるタイミングで、ある程度のデータの整形・補正は、必須なのかなぁ と思っています。
そう、同じ事をしている 検索エンジン には、頭が下がります。 しかも、元データを弄らずに ... 。
あぁ、取り止めもない 文章になってしまいました。 ご勘弁下さい。 .
0 件のコメント:
コメントを投稿