INDEX 重複キーが有ると困るんです(^^); と チェックボックス 応用編

--- 2018-05-22 ---

 

設計の基本形

あれこれござるが、重複キーなお話しデス

 

プライマリキー、Index が重複すると困りますよネ

どうやって、重複キーをチェックしますか？

 

Text File 系だと、Sort をかけてチェックする？

それとも、DB に登録しながら、チェックする？

 

結局チェックはしないとイケません

件数が少なければ、どちらでも良いのでしょうが、

一定件数超えるとなると、自分なりのしっかりした考え方が必要です

 

最終的にはユーザさまに迷惑がかかります

遅い！ (^^); 一言です

 

私的によく使うのが、

重複キーにはプライマリキーを逆用します

 

具体的には？

P-Key を指定したテーブルと無いテーブルの2つを用意します

 

チェックや加工が必要な、.csv などのデータは一旦、キーの無いテーブルへ書き出します

 

その後、キーの有るテーブルへ、キー無しから一括インサートしちゃうのです

 

これだと速いし、2個目は普通に弾かれます

何かの基準で、並べれば、その順番に書いてくれます

 

ロジックも至ってシンプル

メンテナンスもし易いです

 

 

次がこの応用編

P-Key を上手く使えば、重複なしのIndex Table が作成可能です

 

これを使って、よく有るチェックON だけ、印刷する！

みたいなデータ抽出が可能になります

 

沢山の抽出項目から、必要なデータだけを印刷したい

そう言う使い方が出来るのです

 

例えば、日付の範囲で抽出し、

日付の範囲のP-Key とチェックOn/Off をテーブルへ一括して書き込みます

 

こうすると？

元のDB に100万件のデータが有ったとしても、

日付の範囲で一旦、抽出できるので、

それだけでも抽出件数は少なくできます

 

INSERT INTO ... SELECT ...

な感じの一括処理は速いです

 

DB は、極端に言えば、一括処理が出来る所にポイントが有ります

 

これを1件づつ処理するので有れば、

逆に、

テキスト系なファイルの順読みの方が遥かに高速です

 

文面だけでは伝えるのは難しいですが、

結局そう言う事なのネ

 

自分なりにテストして、

自分なりに納得できる方法を考えましょう

 

それが出来たら、

このカキコの意図が分かると思います

 

 

同じ様な事ですが、

2つな処理に応用できます

ちとプログラマなカキコでございました

 

 

(補足) 的な？ 2018-05-23

少し言葉足らずな所も多数でございました

 

Access のメリットは？

DB がサーバ側、ローカル側、どちらでも簡単に作れます

なので、

同じ画面を複数で比較したいと思っても？

業務系なコンパイルなソフトでは中々簡単に出来ません

しかし、

Access ですと？DB、APP、それぞれ分離して作っていれば、APP 側のソフト(Access) をコピーするだけで同じ作業が可能です

非常に便利！

でもネ？

ソフト屋さんからすると？

コピペでソフトを複製されると困るのですョ

(^^);

考えて頂ければ分かりますが、時間を掛けて作っても複数売れれば元は取れます

でもコピペでイケるとなると、コピーするでしょ？やっぱりネ

ソフト屋さんは？ご飯が食べられなくなるのデス

(^^);

中々厳しい！便利なAccess だとご飯が食べられず、不便なソフトだと裕福になる

な感じです

 

それはさて置き、、、

分離なお話しです

 

先程のP-Key 有るのと無いのテーブルですが、どちらに作るべきかも有ります

 

(答え)

サーバ側: P-Key 付、元々のDB ですから当然です

ローカル側: P-Key 無、Access APP を置いてる側です

 

一時ワーク的なテーブルは、ローカル側、C ドライブ、D ドライブです

当然、ユーザ側に存在するので、このテーブルは高速です

 

しかも、チェックボックス的な使用だと？

同じ検索-->印刷でも、ユーザそれぞれで無いと困ります

 

サーバ側で1つのテーブルですと？

実質1人しか使えませんネ

 

コンパイルかける系な業務アプリでも、Access 的な使い方は当然できます

しかし、1つのテーブルに複数のユーザが存在しなければならないとすると？

端末ID、IP 的な、MAC ADRESS 的な固有の番号が必要になります

更に言えば、ネットワークにも負荷がかかります

大量のデータを扱う時は、どう使うべき物なのか？

これをキチンと分かっていないと、DB がサーバだから！な理由だけで設計するとユーザ側は只々遅い！結局、使えない！なシステムになってしまいます

 

ms は、Access DB は、あくまでもローカル側、ユーザ一対一な感じの使用を推奨してます

DB とは言え、Access ですから、細かい作業は難しいのです

同期的なCommit とかネ

 

これもプログラマ レベルで回避可能ですが、複数の人が開発すると、それぞれでレベルが違いますので、出来上がったシステムで、あっちは使い易いけど、こっちは不具合多発で使い辛い！な感じになります

 

そう言う事が無い様に、SE システムエンジニアの設計能力が試されます

 

SE でも、実際に1度もプログラムを組んだ事、まともにシステムを組んだ事が無い人がかなり居ます

私には信じられませんが、本当です

 

コーダ、コードが書ける人

プログラマ、考えてプログラムが書けるSE の前身、中間的な人

SE 設計できる、ユーザとの折衝的な営業みたいな事が出来る人

 

コーダさんは、ほぼ見た事ないですが、SE がPG の延長線上に無い様な業界になっております

 

名前だけは、それなりデスが、残念な大手が多いですネ

(^^)?

 

ちと長くなりましたが、

1つテーブルを増やすにしても、どちらが良いのか検討する必要が有ると言う事です

 

Access はDB の簡易版です

別に、Access なくてもローカル側で一時的に使っても、良いのダョ

素人系な？ SE、PG さん達へ (^^)

 

おしまい！

 

---

明日見むら

村長さんでした

(^^)/ index