「トランザクション」を含む日記 RSS

はてなキーワード: トランザクションとは

2019-04-10

anond:20190410160005

QRスマホ(読取装置)と電波(決済システムとの通信)が要るだろうが。

トランザクションとやらも発生するだろう?違うのか?

増田どもって、片方ばかり担ぐのな、普段から思考が偏ってる連中。

anond:20190410155649

Felicaリーダーの事ならその通りだが、Felicaで決済するためには読み取ったカード情報からなんか決済サーバーに決済トランザクション情報を送ったりなんだりせなあかんのやで。

まりPCが無いとダメなんだが、多分2019年現在でもそういうFelica決済を行えるPOS端末は月額1万円切るか切らないかくらいの費用が掛かるはず。

それよりは安いし導入しやすいやろ。

2019-03-24

anond:20190324094739

SQLアンチパターンではないが、デッドロックについても投げっぱなしのあのSELECT FOR UPDATEの説明はなんなのかね。

1回のトランザクションでupdateを2回発行する場合と1回のSQL複数行のアップデートをする時はデッドロックリスク考慮するってだけで、かなり初心者にはありがたいと思うんだけどね。

1回のトランザクション複数回update文を投げるケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value where id = 2;

tA =# update t1 set column = value where id = 2;
tB =# update t1 set column = value where id = 1;
tB =# ERROR:  デッドロックを検出しました

1回のSQL複数行のアップデート文を発行するケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value -- update all record

tA =# update t1 set column = value where id = 2;
tA =# ERROR:  デッドロックを検出しました

あと、先勝ち後負けを実現するのはSELECT FOR UPDATEではなく楽観的ロックな。

tA =# begin;
tA =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tB =# begin;
tB =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tA =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 1
tB =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 0

MySQL存在しないレコード更新しようとするとギャップロックになるから注意な。

SQLアンチパターンコピペするアンチパターン

キーレスエントリー(外部キー嫌い)

外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか

外部キー貼らなかったことによって、俺はこんな被害だしたぜっての是非教えてほしい。

すぐに思いついたケースは

とかを思いついたがこんなケースで合ってるのか?こんなケースより間違った外部キーの使い方したほうが家に帰れなくなるケースのほうが多いと思うぞ。間違った使い方をしていて、システムが太ってくるとこんなケースが出てくる。

特に下2つは害悪で、SQLアンチパターンコピペして、「おまえらw外部キー嫌いはアンチパターンだぞwww」ってやるのもいいけど、同じくらい間違った使い方を注意喚起したほうがいいと思うよ。DB識者のなかでは「そんなの常識w」かもしれないが何もしらない初心者が真似をしてお家に帰れなくなるのは辛くないか

そんな経験していると、DB初心者は「せや!ユーザテーブルに退会フラグ論理削除フラグ持ったろwww うはw天才www」とかなって今度は削除フラグ持つなおじさんが出てくるぞ。しまいにはこれですよ。

http://b.hatena.ne.jp/entry/s/qiita.com/ponkotuy/items/6049388d564fb4385f4e

初心者どうしたらいいんでしょうね(*_*) 是非、DB識者には明るい未来を示して欲しいね

俺?俺はAndroidエンジニアSQLiteは使わないか関係いね

RDB初心者の俺が恐れ多くも案を出すと、FK作成する前に、そのテーブル性質予測することが大事なんじゃないかね?大量に発生するログデータなのか、大事トランザクションデータなのか、第2正規化しただけのただの情報テーブルなのか。大事トランザクションデータだったら親が削除された時にどこにどうやって退避するか。大量のログデータだったら、親が削除される時どうアプローチするか。とか恐れ多くも予測するね。

ちなみに外部キーいかER図出せないってのはそれはツールの作りであって、FK制約とは関係ないんじゃないの。バリデーション(外部キー)はセキュリティ対策(ER図を作成する)の為、実装するってのと個人的に同じことだと思っている。

から先ずは外部キー使用していなくて「こんな被害を出した」ってのを聞いてみたい。

2019-03-17

anond:20190317195914

用途の違い

マスター辞書みたいなので社員コード社員名とかを対応させる表

トランザクションは日々の処理だから日時の売上データ等を格納する

2019-02-06

COBOLってこんな言語

日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。

https://anond.hatelabo.jp/20190205192741

COBOL本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルデータ処理を想定している感じ。

SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通JavaRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLコンパイル単位で、それごとにソースファイルが分割される。ひとつソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。

で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイルsedawkテキストファイルCSVファイルを行ごとに処理するのとちょっと似てるけど、COBOL場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的データの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だからUIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。(混乱するから余談だけど、今のCOBOLSQLを使って普通RDBにもアクセスできる。ただ使い方としては、RDBファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初最後だけみたいなのが普通

入出力がファイルから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグ不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。

データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOLプログラム側、というのがSQLと一番違うところかも。つまり、このデータファイル構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。

まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通大企業は途中でSunかに置き換えてその後Linuxクラウドさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題

2018-12-20

自分デッドロック対策トランザクションかけてる時は、primary key昇順で更新するように気をつけるてるんだよ、

でも他の人はselect ... for updateで別トランザクション更新後の値を取得しつつデッドロック対策してて、自分もその書き方に直すとなると結構手間だな

2018-12-04

増田プログラマー養成講座 その23 SQLを巡る物語

前回は、データベース設計について学びました。

今回は、その他のデータベース話題について見てみましょう。

 

 

リレーショナル・データベース理論

問合型言語SQLは、「関係代数」という計算モデルを基に作られたプログラミング言語

一度「関係代数」について学んでおくと、RDBの使い方について、理解が深まる。

↑このスライド作者さんは他にもDB関係資料作成されてるので見ておくといいかも?

 

 

SQL以外の問合型言語

SQL以外にも「SPARQL」、「TMQL」(Topic Maps Query Language)等、いろいろな問合型言語がある。

実際に使う機会は少ないかもしれないが、「問い合わせ」で処理するという発想は参考になるかも?

 

Datalog

Datalogは「Prolog」(論理言語)を源流にもつ宣言的なデータベース問合せ言語。DatalogはSQLと同等の表現力を持つ。

Datalogは様々なプログラミング言語で利用できる。

 

トピックマップ

トピックマップ」は、本の索引もっと機能にしたような仕組みで、RDBとは違う形でデータを蓄積/検索できる。

 

 

RDB以外のデータベース

SQLを使わないデータベースもある。

 

NoSQL

NoSQL一般に "Not only SQL" と解釈される)とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である

関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合操作を利用しないこと(場合によっては単にそのような機能が欠落しているだけ)、水平スケーラビティが確保しやすい事が多いこと、トランザクションを利用できないものが多いことなどが挙げられる。

学術的な世界では、この種のデータベースのことを構造ストレージ (structured storage) と呼ぶことが多い。

 

NoSQLデータベースは、関係データベースのような汎用性は欠くものの、その制約された条件下ではRDBMSより高いパフォーマンスを持つ。

そのためビッグデータソリューションでしばしば活用される。

NoSQLデータベース管理システム有用な場面は、関係モデル必要としないデータを扱う時や、大量のデータを扱う時である

 

有名な実装として、GoogleBigTableアマゾンAmazon DynamoDBなどがある。オープンソース実装も数多く存在し、例えばMongoDBRedisApache HBase、HyperTable, Apache Cassandraなどがある。

 

 

SQLRDBに慣れたら、NoSQLも調べてみよう!

 

 

その他、データベース関係話題

DB運用管理で学んでおきたい話題を列挙してみよう。

 

 

SQL開発物語

問合型言語学習最後に、SQLを巡る物語も見てみよう。(SQL学習ドラマチックで楽しいものにしたいねw)

 

 

RDB活用すれば、大量のデータを処理して、多くの仕事効率化できる。(金持ちへの扉が開かれる。)

暇があったら、SQL物語登場人物も見ておこう。

 

エドガーフランク・コッド(Edgar Frank "Ted" Codd, 1923年8月23日 - 2003年4月18日)は、イングランドまれ計算機科学者

関係データベース理論的基盤であるデータベース管理関係モデル発明した。

 

1960年代から1970年代、コッドはデータ配置に関する理論を構築し、1970年 "A Relational Model of Data for Large Shared Data Banks" (大規模共有データバンクのデータ関係モデル)という論文を発表した(IBM内ではその1年前に公表している)。

しかし、IBMライバルがそれを実装し始めるまで彼の提案を実行に移そうとせず、コッドは失望した。

当初、IBMはIMS/DB収益を守るため、関係モデル実装することを拒んだ。

コッドはIBM顧客自身モデル実装した場合可能性を提示し、顧客からIBM圧力をかけさせた。

そこでIBM関係モデル実装を開発する System R プロジェクトを Future Systems プロジェクトに含める形で立ち上げたが、その開発チームとコッドは分離され、しかもコッドの理論精通した者はチーム内にいなかった。

結果として彼らはコッドの Alpha 言語を使わずリレーショナルでないSEQUEL言語を開発した。

 

ラリーエリソンSEQUEL 完成前に発表された論文に基づいて Oracle を完成させ、先に発売している。

IBMは、SQL/DS を発売した。

幹部技術音痴だと、部下の名案も却下してしまうんですね?

 

ローレンス・ジョセフ・エリソン(Lawrence Joseph Ellison、1944年8月17日 - )は、データベースソフトをはじめとする大手ビジネスソフトウェア企業オラクルコーポレーションの共同設立者であり、元CEO会長CTOである

2014年現在総資産は500億ドルで、世界で5番目の富豪である

 

ニューヨーク出身アシュケナジムユダヤ人母親フローレンススペルマン(Florence Spellman)は出産当時未婚の19歳で、生後9ヶ月のラリーシカゴに住む叔母リリアンエリソンとその夫である義理叔父ルイスエリソン養子として引き取ってもらった。ラリーは実の母の名も知らず育ったが、48歳の時に初めて対面した。

 

高校時代秀才だが、無愛想な生徒だった。イリノイ大学アーバナシャンペーン校に二年生まで通っていたが、リリアンの死後まもなく退学。カリフォルニア州北部で夏を過ごした後、シカゴ大学で学ぶために実家に戻ったものの三ヶ月でまたも退学し、カリフォルニア移住。この頃、コンピュータに触れ始めている。

 

1970年代エリソンはアンペックスで働いた。彼の関わったプロジェクトのひとつCIA向けデータベース開発があり、彼はそれに「オラクル (Oracle)」と名づけた。

エリソンエドガー・F・コッドのリレーショナルデータベースシステムに関する論文 A Relational Model of Data for Large Shared Data Banks に触発され、1977年自己資金1400ドルオラクル設立した。

彼はIBMのSystem Rデータベースがコッドの理論に基づいたものであると聞き、Oracleもこれと互換性のある製品にしたかったのだが、IBMエラーコード秘密にすることによって互換製品が出てくるのを防いでいた。

オラクル最初製品Oracle 2であり、Oracle 1は存在しない。このリリース番号は、それ以前のバージョンバグが全て解決されていることを暗示しようとして付けられた。

 

1997年8月ラリーエリソン親友スティーブ・ジョブズアップルに戻った後、同社の取締役就任した。2002年9月20日取締役会に出席する時間が充分に取れないことを理由アップル取締役を辞任した。

この人、キャラクター的にはあまりきじゃないけど、行動力はすごいね

コッド博士論文を見て自分RDBを作っちゃった!

Oracleバージョンを「2」から始めて、改良されているように見せかける。~ちょっと詐欺っぽいけど、商売うまい?w

 

 

 

SQLデータベース活用して、素敵なアプリWebサービスを開発してください。

では、これでいったん、増田プログラマー養成講座を終了します。

御清聴いただき、どうもありがとうございました。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラム=データ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミングの練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181101230220 増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181104161900 増田プログラマー養成講座 その17 Webアプリの骨組み

anond:20181104233013 増田プログラマー養成講座 その18 SQLデータの追加と取得

anond:20181110120715 増田プログラマー養成講座 その19 SQLデータ更新

anond:20181110182445 増田プログラマー養成講座 その20 SQLデータの削除

anond:20181111205255 増田プログラマー養成講座 その21 データベース設計 (1)要件定義

anond:20181119224031 増田プログラマー養成講座 その22 データベース設計 概念物理

anond:20181204142213 増田プログラマー養成講座 その23 SQLを巡る物語 ←★今ここ★

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-11-28

チケット転売技術的に防ぐアイディア

チケットを「そのチケットの何倍もの価値を引き出せる秘密鍵の所有者」に販売することで、転売を防ぐというアイディア

 

話を具体的にするためにビットコイン説明する。

・1000円のチケット販売すると、チケット購入者が持つ「1万円以上が入ったビットコインアドレス」に結び付けられる。

・この1万円は特に問題が起きなければ常に購入者の所持しているものであり、デポジットのように一時的販売者に渡す必要はない。

チケット購入者は、チケットを利用する際にこのビットコインアドレス秘密鍵を使って送金トランザクション作成することでチケットを持っていることを証明する。

・その瞬間にビットコインアドレスに入っている金額が1万円未満になった場合、そのチケット無効判断される。

・これは単に秘密鍵を持っていることの証明なので、その送金トランザクションは実際に処理される必要はなく即座に破棄していい。

 

これによって、いくつかの転売防止効果が期待できる。

1つ目の防止効果は、1000円のチケット譲渡するときに1万円が引き出せる権利とセットでないとそれを譲渡できなくなるというもの転売屋はチケットを売った後に客が1万円を持ち逃げするリスクを負う。

2つ目の防止効果は、転売から購入したチケット転売屋がいつでも無効化できるチケットだというもの転売はいつでも1万円を引き出せる秘密鍵を所持しているため、客は購入したチケット無効になるリスクを負う。

3つ目の防止効果は、1000円のチケットを100枚購入するためには、100万円の価値を持っている必要があるという点。単純に買い占めがしづらくなる。

2018-11-20

イエロースター互助会考えた

クロールして自動スター1000個ぐらいつけて常にトップコメにするの。

イエロースターは1垢で何個でもつけられるし賢くない?

1ブクマスター100個10円ぐらいのマイクロトランザクションでやろうと思うんだけどどう?

2018-11-11

増田プログラマー養成講座 その21 データベース設計 (1)要件定義

前回まで、データベースを使ったWebアプリ作成して、SQLの使い方を学びました。

今回からデータベース設計について学んでみよう。

 

参考書

これらの参考書ガッツリ読めば、データベース設計のやり方は分かる。

 

リレーショナル・データベースは昔からある枯れた(=安定した)技術なので、鉄板ノウハウが蓄積されている。

先人の知恵に沿って使うなら、データベース設計で悩む余地は少ない。=攻略は意外と簡単

 

データベーススペシャリスト教科書

経済産業省認定情報処理技術者試験で「データベーススペシャリスト」という資格もある。

 

データベースエンジニア」という肩書きを名乗れば、ただのプログラマーよりも高給取りになれる。勉強した後、自分知識棚卸してみるつもりで資格を取ってみるのもいいだろう。

データベーススペシャリスト試験教科書には、浅く広くDB知識網羅されているので、1度眺めてみたらいいかも。

 

 

 

データベース設計の流れ

データベース設計(database design)は、ソフトウェア開発工程においてデータベースの詳細なデータモデルを作る工程である

 

  1. 要件定義:「CRUD表」の作成
  2. 概念設計:「概念モデル」の作成 → ER図(実体参照モデル)の作成
  3. 論理設計:「論理モデル」の作成 → テーブル定義表の作成
  4. 物理設計:「物理モデル」の作成 → 論理モデルを実際にデータベース上で作成インデックス作成など

(分類方法にもよるけど)データベース設計は、このようなステップを経る。それでは順番に見ていこう。

 

 

 

1.1 永続化するデータを決定する

いわゆる「要件定義」だ。

実際にシステムを使うことになるユーザーヒアリング調査して、データベース内に永続化(格納)すべきデータを決定する。

 

CRUD表とは?

データCRUD操作(Create 追加、Read 参照、Update 更新Delete 削除)が、いつ、どこで発生するか?をまとめた表のこと。

 

データベース 設計 CRUD表」等のキーワードGoogle画像検索してみよう。どんな表か分かる。

↑このページの「図2 標準的CRUD図(例)」みたいな表を作って確認すれば、扱うデータの過不足がなくなる。

 

複雑なシステムだと、完全なCRUD表を作るのは面倒だよねw

だが安心して欲しい!

押さえておくべきポイントはあるので、そこだけ手抜きをしなければ、大失敗は避けられるだろう。

 

マスタートランザクションの違い

実は、後でテーブルを作るときに、データ更新頻度によって2種類に分類できるんだ。

 

 

トランザクションデータの扱いは、気を付けないとデータベースの性能低下に直結する。

どっちのタイプデータなのか?要件定義の段階から見分ける癖を付けておこう。

 

要件定義練習

試しに、Amazonのような通販サイトなら、どんなデータを扱うことになるのか?想像してみよう。

仕入先、在庫数、受発注配送会社顧客情報商品カテゴリー、商品スペック、などいろいろあるだろう。

いつどこでCRUDが発生するか?どれがマスターデータで、どれがトランザクションデータだろうか?

 

 

 

(ここまでの説明URLを8個も貼ってしまったので、続きは次回にしよう。)

次回は「概念設計」以降のステップを見てみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181101230220 増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181104161900 増田プログラマー養成講座 その17 Webアプリの骨組み

anond:20181104233013 増田プログラマー養成講座 その18 SQLデータの追加と取得

anond:20181110120715 増田プログラマー養成講座 その19 SQLデータ更新

anond:20181110182445 増田プログラマー養成講座 その20 SQLデータの削除

anond:20181111205255 増田プログラマー養成講座 その21 データベース設計 (1)要件定義 ←★今ここ★

anond:20181119224031 増田プログラマー養成講座 その22 データベース設計 概念物理

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-28

増田プログラマー養成講座 その13 SQL文法

前回は、データベース参考書を見た。

今回は、DBで使うプログラム言語SQL」の文法を見てみよう。

 

リレーショナル・データベース(Relational Database、RDB)とは?

WikipediaRDB説明を見てみよう。

関係データベース(relational database)は関係モデルにもとづいて設計、開発されるデータベースである

関係データベース管理するデータベース管理システム (DBMS) を関係データベース管理システム (RDBMS) と呼ぶ。

Oracle Database、Microsoft SQL Server、MySQLPostgreSQLDB2、FileMakerH2 Database などがRDBMSである

 

関係モデルIBMエドガー・F・コッドによって考案された現在もっとも広く用いられているデータモデルである

データベース利用者は、クエリ(問い掛け)をデータベースに与え、データ検索したり、変更することができる。

 

データは表に似た構造管理されるが、関係と呼ぶ概念モデル化される。

関係は組(タプル、表における行に相当する)、属性アトリビュート、表における列に相当する)、定義域(ドメイン)、候補キー(主キー)、外部キーなどによって構成される。

SQLなどに代表されるデータベース言語(問い合わせ言語)を用いて、関係に対して制限・射影・結合・和・差・交わりなどの関係代数演算(集合演算を含む)ないし関係論理演算を行うことで結果を取り出す。

関係複数持つことも可能で、互いを関連させることも可能である

要するに、

 

SQLとは?

WikipediaSQL説明も見てみよう。

SQLエスキューエル)は、関係データベース管理システム (RDBMS) において、データ操作定義を行うためのデータベース言語(問い合わせ言語)、ドメイン固有言語である

エドガー・F・コッドによって考案された関係データベース関係モデルにおける演算体系である関係代数関係論理関係計算)にある程度基づいている。

 

SQLは、シークェルと読まれることもある。

これは、SQLの元となったデータベース言語が、IBMが開発したRDBMSの実験実装であるSystem Rの操作言語SEQUEL (Structured English Query Language)」であったことが由来である

SEQUEL (Structured English Query Language)」を略して「SQL」と呼んだらしい。

 

  1. 質問する、尋ねる
  2. 問い合わせ[クエリー]を行う

英語クエリーは、質問する、問い合わせる、という意味なんだね。

 

SQL3分

SQL説明するとき、3つのグループに分類される。

 

↑このページをよく読んでくれ。理解できたらSQL説明は終わりだ!!!

 

 

 

…というと、説明することがなくなるので、ちょっとまとめておこう。

このページの「表1●SQLDDLDML,DCLの三つに大別できる。このうちプログラマが最も多く使うのはDMLだ」という図を見てみよう。

 

という3種類に分けてる。順番に見てみよう。

 

DDL(Data Definition Language:データ定義言語

データベーステーブル、ビュー、インデックスユーザーなどを作成/変更/削除するときに使うSQL

これでデータベースを使う準備ができる。

  • 「CREATE」…作成する。
  • ALTER」…変更する。
  • DROP」…削除する。

 

DML(Data Manipulation Language:データ操作言語

データ操作するときに使う。いわゆる「CRUD」のことで、SQLのうち、このDMLを覚えれば、とりあえずRDBは使えるようになる。

CRUD(クラッド)とは、ほとんど全てのコンピュータソフトウェアが持つ永続性の4つの基本機能イニシャルを並べた用語

その4つとは、Create(生成)、Read(読み取り)、Update(更新)、Delete(削除)である

ユーザインタフェースが備えるべき機能情報の参照/検索/更新)を指す用語としても使われる。

 

この中で一番活躍するのは、「SELECTコマンド命令文)だろう。

SELECTは、いろんな条件を付けてデータを絞り込む/加工することができて、便利なんだ。(Excelなどの表計算ソフトよりも高機能

 

JOIN(結合)

RDBは「リレーショナル」(関係)という冠言葉が付いてることからも分かるように、関係がある表と表をくっつけて、データを加工できる。

表と表をくっつける操作のことを「結合」という。

SQLでは「JOIN」というコマンドを使って表と表を結合できる。

↑このページにある丸と丸が重なった図を見てくれ。この図は「ベン図」といって包含関係を示す図だ。図を描いて塗りつぶせば、欲しい部分が分かりやすくなるだろう。

 

結合の種類

表と表のつなげ方には、何通りかパターンがあるよ。

  • 結合は、「内部結合」(INNNER JOIN)と「外部結合」(OUTER JOIN)の2種類に分類できる。
  • 外部結合はさらに、「左結合」(LEFT JOIN)と「右結合」(RIGHT JOIN)と「完全結合」(FULL JOIN)の3種類に分類できる。

 

内部結合は単純だ。外部結合はちょっとややこしい。

外部結合は「LEFT JOIN」の形がよく使われると思うので、まず最初にLEFT JOINの仕組みを理解すれば大丈夫だろう。

(LEFTの仕組みを基準にして、RIGHTやFULLとの相違点を意識すれば、表のつなぎ方を間違えにくい?)

 

DCL(DataControl Language:データ制御言語

トランザクション」は、データ更新に失敗したとき、元に戻せる機能だ。(安全装置

  • 「COMMIT」…更新処理の確定
  • 「ROLLBACK」…更新処理の破棄

 

言葉だけだと意味が分かりづらいと思う。

Google画像検索で「トランザクション」を検索して、分かりやすそうな図解を探してみよう。

↑このページの「図1 処理失敗による不整合の発生」を見てみよう。

 

銀行で口座間の送金を考えてみる。Aさんの口座からBさんの口座へ50万円送金したい。

  1. Aさんの口座から50万円減らす。
  2. Bさんの口座に50万円追加する。

この2つの処理が両方とも成功しないと、送金は失敗だ。(Aさんは送金できてないのに貯金が減ったら怒る。Bさんは送金されてないのに貯金が増えてラッキー!)

AとBの両方が成功したら更新処理を確定する。AとBのどちらか、または両方が失敗したら更新処理は破棄してなかったことにする。(やり直し!)

これがトランザクションだ。

 

クレーム対応難易度

ちょっと話がそれるけど、トラブルの重大さ=クレーム対応難易度について考えてみよう。

  1. 人身事故 …人命にかかわる事故は取り返しがつかない。文句も一番キツイ絶対ミスがあってはならない分野のシステム開発はなるべく避けよう。
  2. 金銭絡み …(命の次に)お金大事という人は多い。人は金の話になるとシビア文句も強烈だ。決済など金銭絡みのシステムでは、RDBトランザクションを使おう。
  3. 上記以外 …その他のクレームは、それほどハードではない。匿名掲示板とか、どうでもいいゴミ情報投稿されるシステムなら、トランザクションは使わなくてもOKだろうw

 

DB管理ツール

ここまで、SQLRDB操作する方法について話した。

RDBは、SQLコマンド操作するだけでなく、DB管理ツールを使って操作することもできる。

DB管理ツールについても知っておこう。

 

この講座では「phpMyAdmin」というDB管理ツールで「MySQL」を操作した。

他にも、Google検索で「DB 管理 ツール GUI」などで探してみよう。商用だけでなく無料でも便利なソフトがたくさんあるね。

 

など。

 

SQLパズルだ!

SQLを駆使すると、欲しいデータをホイホイ取り出せる。

SQLコマンドを組み立てる作業パズルのような要素もあるので、遊びだと思ってSQLに取り組んでみて欲しい。

SQL パズル」でGoogle検索すると、いろんなテクニックが紹介されているので、時間があったらチャレンジしてみよう!

 

SQLの話は、それだけで1冊の本になるぐらい広範だ。今回は、SQL概要説明するだけになってしまった。

SQLの詳細については、前回紹介したSQL参考書などを読んでみてね。

 

まとめ

 

次回は、データベースを使ってWebアプリを作ってみよう!

データベースって便利だな~~~!!!」と実感して欲しい。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマ養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマ養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマ養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマ養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマ養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマ養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマ養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマ養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマ養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマ養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマ養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマ養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマ養成講座 その13 SQL文法 ←★今ここ★

anond:20181031014212 増田プログラマ養成講座 その14 Webアプリの試作品作成

anond:20181024214737 増田プログラマ養成講座 コンテンツ一覧

2018-10-24

anond:20181023184616

データベースSQLの使い方をどうやって説明するか?検討してみた。

RDBMySQL使用XAMPPMySQLphpMyAdminですぐに練習できるから

 

RDBの仕組み

  1. RDB歴史
  2. RDB概要
  3. SQL誕生の背景(問合型言語計算モデルは「関係代数」)→ 関係代数 (関係モデル) - Wikipedia https://ja.wikipedia.org/wiki/%E9%96%A2%E4%BF%82%E4%BB%A3%E6%95%B0_(%E9%96%A2%E4%BF%82%E3%83%A2%E3%83%87%E3%83%AB)
  4. 表計算ソフトExcel)とRDB比較 

 

SQL

文法コマンドの種類

  1. データ定義言語 (DDL: Data Definition Language)
  2. データ操作言語 (DML: Data Manipulation Language)
  3. データ制御言語 (DCL: Data Control Language)

 

データベーステーブル、ビューの作成
データ操作CRUD
トランザクション
バックアップリストア

 

DB設計

論理設計物理設計

  1. データ中心アプローチDOA)、ER
  2. 正規化インデックスの張り方

この手の話は、情報処理試験データベース教科書かに、よくまとまっている。

 

MVCフレームワークWebアプリを作り、データストアとしてRDBを使ってみる。

 

RDB以外のデータストア

 

データベース参考書の紹介

ミックさんの本が分かりやすい?

 

最初から欲張って、てんこ盛りにしても混乱する?

要点を絞って、情報量を絞り込まないといけない。

最低限は、

  1. SQLCRUDを書けるようにすること
  2. WebフレームワークからRDBを使えるようにすること

 

こんなかんじかなー?

2018-10-14

anond:20181014211256

2018-08-29

anond:20180829102525

言うてNoSQLでアクロバティックなトランザクション処理するよりは大人しくRDB使うやろ。

実際google検索したときに出てくるリンクデータをどういうデータだと位置付けているかは知らんけど。

2018-08-27

anond:20180827112309

1b

明確に違法性のあるトランザクションがあって、一刻も早く消さないと深刻な損害があると仮定した時、誰がどう対応するのか、できるのか。色々探したけど見当たらない。

The DAO 事件

web3.0が胡散臭く見えて仕方ない話

『web3.0ってなんぞ』という方はとりあえず↓など参照しつつ。

【事例で解説】「Web3.0」とは何か?普及するのか?

http://www.ikedahayato.com/20180219/74516919.html

まぁ新しいもの忌避感を感じるのは当たり前だし、Twitterやらを『中央集権的』なんて書くのはひどい印象操作でムカつくって感情的反発もあるけれど、それにしたってこれどうなの?

論点整理

何より不安なのが、ブロックチェーンを利用することで

1)中央とか管理者といった概念がないよ

2)誰にも改竄できないよ

みたいに謳われている辺り。ほんとにござるかぁ?

1a

P2Pの、暗号化された、ブラックボックス通信が一部のアプリケーションカード決済時だけでなく広く当たり前になると、もう素人セキュリティ対策なんてできなくない? 何処と何を通信してるのか分からないよね。自分情報自分管理できるようになるって謳い文句の逆に聞こえる。何らかの形でプロの助けを得るか、あるいは開き直ってガバガバになるしかないような。

一応は『本人の了承』を取り付けてから個人情報を売り物にする方が幾分マシだと思いますが。

1b

明確に違法性のあるトランザクションがあって、一刻も早く消さないと深刻な損害があると仮定した時、誰がどう対応するのか、できるのか。色々探したけど見当たらない。

仮にそれが、本当の意味で誰にもできないんだとしたら、そんなリスクを抱えたプロトコルは出来損ないだ。

仮にこの叙述が嘘で、『本当は権力者ならごにょごにょできる』としたら、やっぱり出来損ないだ。

2

にもかかわらず看板上は『誰にも改竄できない』って。おい。

ブロックチェーン解説読めば何処にでも書いてある。『仕組み上、割に合わないから誰もやらない』って。

短期的に損する前提なら出来るんでしょ。金銭目的じゃなければ。もちろんそれは一般人が気軽にできる範囲ではない設備投資が前提だけども。

できないは嘘。できる。

お金さえあればできる。

お金のある人だけができる。

……普通にディストピアだよねソレ。

ちっとも良いことを書いていないのに、文章上の味付けで良く見せている。現状みつかるweb3.0の解説にはそういう印象を抱いています

メリットは分かったかデメリットも教えてくれと。

おわり

以上、基礎レベルでの誤解や知識不足はあると思います煽り釣り意図はないので教えてくださる方がいればありがたいです。

2018-08-12

anond:20180812152405

どうでもいいけどマスタやトランザクションにM_だのT_だの接頭辞付けるの習慣あるとこ多いけど見づらいってずっと思ってる

後ろに付けるんじゃ駄目だったんだろうか

2018-05-11

ドルフィンアタックというハッキング手法を知っているか?海の中で流行ってる。

から一ヶ月後、あるVtuberの生配信中に、そのインシデントが発生する。

そうやってスマートアシスタントが一斉にトランザクションを発生させた所へ乗じて、狙いすましたように、闇の者たちが破壊活動を始める。

それが後に6.11事件と呼ばれる出来事の端緒となる。

ネット接続されたあらゆる端末が保持する全データのうち、実に3割が影響をうけ、社会インフラ機能不全に陥る未曾有のサイバーテロにまで発展する。

警告はした。このメッセージを受信した光の増田たちは、今すぐLovelabo::Anonymノードへ参加し、対策を整えよ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん