RDBとかDBMSを勉強しだしたばかりの良い年のおっさんなので
本職の方のツッコミは優しくしていただけたら嬉しいな(笑)
会社で課題があるものの、
それを解決できる人が(私以外)居なくて
興味もあったし
図書館で借りてきた本です。
・データベースのきほん
9784798135168
1923055022003
ISBN 978-4-7981-3516-8
・基本がわかるSQL入門
9784297116590
1923055024809
ISBN 978-4-297-11659-0
今の世の中はデータベースで全て管理されていると言っても過言ではないと思っています。
マイナンバーカード、給与明細、税金の支払い、
皆さんがお使いのみんカラもデータベースが基礎にあります。
ブログを書く時の
・日付(年)
・日付(月)
・日付(日)
・気分
・テーマ
・カテゴリ
・タイトル
・ファイル画像の保存方法とその保存先
・本文
・画像リンク
etc.etc.
みんカラがRDB(=Relational Database)で作られているのか?
今流行りのNoSQLのJSON(=javascript Object Notation)で作られているのかはわかりませんが、
Whois検索を行ったところ
Domain Information: [ドメイン情報]
a. [ドメイン名] CARVIEW.CO.JP
e. [そしきめい] やふーかぶしきかいしゃ
f. [組織名] ヤフー株式会社
g. [Organization] Yahoo Japan Corporation
k. [組織種別] 株式会社
l. [Organization Type] Corporation
m. [登録担当者] HT46858JP
n. [技術連絡担当者] KM56800JP
p. [ネームサーバ] ns-833.awsdns-40.net
p. [ネームサーバ] ns-1434.awsdns-51.org
p. [ネームサーバ] ns-1910.awsdns-46.co.uk
p. [ネームサーバ] ns-228.awsdns-28.com
s. [署名鍵]
[状態] Connected (2023/06/30)
[登録年月日] 2013/06/07
[接続年月日] 2013/06/07
[最終更新] 2022/08/05 15:06:09 (JST)
ということなのでAWS(=Amazon Web Service)を使っているのではないかと・・・
AWSもいろんなサービスがあるので、
ドメイン情報だけでは私ではどんなデータベースを使っているのかは
わかりません^^;
会社のHP・・・
例えばネットで注文、店舗で受取~
というのもオムニチャンネルという仕組みを使っていますが、
その大本にはデータベースが潜んでいます。
店舗のPOSデータを元にした在庫数を使って、
スマホの位置情報から
近い順の店舗で在庫数を表示させる
と言った情報を表示させることが出来るのも
データベースがあってのことになります。
ただ、データベースというのは一般の人の目に触れにくいところにあります。
簡単に触れられてしまうと情報流出ということも・・・
なので、データベースというのはわかりにくいと言われていますが、
わかりにくいような仕組みにしているので当たり前ですよね^^;
因みに、一般の人がみてマニュアルがわかりにくいというのも
マニュアルを作成している人がエンジニアという人種ということに依存しています。
エンジニアという人種というものは
必要最小限でその機能のみを説明しつつ
その機能を制限することがないように最大限の考慮をするというのが当たり前なので
その説明がわかるのはエンジニアしかいないというのも当たり前です^^;
私も色々マニュアルを作成してきましたが、
極力わかりやすいマニュアルを作成しているつもりですが、
その道具の使い方をカードとしてみるのか
箇条書きで使い方を説明されているのをみるのか
という違いがあるようで、
まだまだマニュアルの使い方は下手です^^;
話をもとに戻して、
いまでもデータベースの主流と言われているのは
Relational Database(リレーショナルデータベース)です。
ExcelやGoogleスプレッドシートをイメージするとわかりやすいかと思います。
行にデータが追加されていき、
列は年齢や性別などといった情報を入力するようになり、
全ての行がIDと呼ばれる一意の番号で管理されるようになっています。
ですが、それだけを使うことは難しいので
Relational Database Management System(リレーショナルデータベースマネージメントシステム=RDBMS)
の仕組みで必要な情報をデータベースから出してきて、
主流の方式ではそのデータをブラウザで見れる形式にして(Webサーバー)
ユーザーに提供するという方式を採用している場合が多かったと思います。
(Web3層)
ただ、今の主流というとブラウザでの閲覧を出来なくして
アプリのみしか情報の取り出しを出来なくする
ネイティブアプリというのがかなり主流になっているようです。
(Google Apps等)
ネイティブアプリというのは例えばスマホにアプリをダウンロードさせて、
アプリからデータベースに接続することで、
例えば駐車場の空き情報を確認すると行った使い方等がされているかと思います。
ネイティブアプリはスマホ個体の動きに合わせる必要があり
この個体では動くが、別の個体では動かないという不具合が発生するものの
データベースに直接接続することが出来るので、
DBMS(=Database Manegement System)や
Webサーバーを用意しなくて済むことで
コストを抑えられるということと、
今どきはローコードやノーコードのアプリ作成ツールが台頭しているので
(日本ではエンジニアが圧倒的に少なすぎ)
エンジニアではない人種(エンジニアは普通の人とは違う変人(笑))の人でも
アプリを作ることが出来る環境になっていて、
スマホ同士の個体の違いはアプリ作成ツールの方で吸収してくれるので、
個体差を気にする必要もない
という時代になっています。
因みに私は会社の人から普通に尊敬を込めて変人と言われています(笑)
前からそういう節があったのですが、
そういう本を読み出してからよりその傾向が強くなっているようで
エンジニア語を喋るからわかりません!
と言われることがあります^^;
いい年になってこれから脳細胞をどれだけ活性化出来るかわかりませんが、
エンジニアという人種は面倒くさいのをなくして
自分が楽をしたい(そのおまけで世の中に貢献できるものが出来る)
と考えている人が多いようで、
私も面倒なルーティーンというのは極力無くしたい方で、
無限にというとエンジニア失格なのでしょうが、
自分が楽をするためには無限の努力を出来る方なので
自分が楽をするために日々努力をしています(笑)
その中でQiitaで見つけた
後輩エンジニアを絶望させるDB設計方法4選
というのは
中々灰色の脳細胞が活性化されました。
>エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。
あるある~
同じような処理は、処理のやり方を一般化して
他のところでも同じ様に使えるようにしがちです^^;
この、
ちょっと違うけど似たようなことだから同じ様に使える
という考え方も変人以外には分かりにくいことらしい・・・
って昨日言われました^^;
>◯◯設計には◯◯運用がつきものである。
リンク先をご覧になって、
こちらのブログを見返して不快になられたら申し訳なく思いますm(_ _)m
ありますよね~^^;
設計がユーザーが使用することをあまり考えていない設計のものは〇〇な運用が発生して
結果人時数が減ってるのかどうなのかわからないというようなものも世の中にはありますよね^^;
会社で導入することになったなんちゃらステーションというSaaSなのですが、
全員が必ずつまずく同意方法にも関わらず、
車内でそのマニュアルの作成をしておらず、
その人の上長にその人の上長に同意してもらうよう言ってもらうという
◯◯運用という^^;
そのSaaS(=Software as a Service:定額制:サブスク=Subscription)は何らかの意図を持ってそのサービスにしているかもしれませんが、
そのSaaSを選択した我が社の担当者が◯◯設計という^^;
今までの少ない人生経験を元に説明しだすときりがないのでもうやめますが、
後輩エンジニアを絶望させるDB設計方法4選
エンジニアをちょっとかじったことのある人にとっては
あるある~という思いとマジで笑いが出るほどの内容と思っています(笑)
ですが、そういう失敗事例を見ると
私は絶対そういうふうにならないようにしようと思って
他の失敗事例を見て
成功事例の案を出そうと思います^^;
ぶっちゃけて言うと、
この世の中の成功と失敗というのは結果論でしか無くて、
それを纏めたのが本やQiita等の媒体であって、
ですが、その成功談・失敗談というのもその状況のピンポイントのモノなので
今の我が社の状況にそのまま当てはまるわけではないので、
その誤差を如何に吸収させて成功に導くというのが
エンジニアの腕になってくるかと思っています。
この辺りの話もペガサスではダイエーやAEONやニトリに
セミナーでしつこいぐらい教育しているようですね。
私が今の会社に居続ける理由は
チーフエンジニアになる
という目標しか無いかもしれません^^;