  |
はてなキーワード: トランザクションとは
最近はレバレッジが効く言語とフレームワークを好きになるようになってきた。
もう言語何でもいいわ。やっぱ静的言語がいいのと十分に熟練度がついてきたのでAPI開発ではGolang使って開発するのは良い。PHP(Laravel)、Ruby(Rails)はやはり生産性が高いので良い。ScalaもMonad Transformerを使ってモナドのスタックを解決していく程度あれでやっていき、あまり悩まないような構成になっていればサクサクやっていけそう。
実はJavaが一番いいんじゃないか…。Springガッツリやったこと無いけど、トランザクションとかもいい感じに効いてくれそうだし、そこそこ生産性高そうだし。
知らんけど。
なんでもいいや。
最も罪深いのは運転手だが、悪は「上級国民！上級国民！」と加害者や家族を的にして石を投げまくる人間にあると思うんだよ。
何故ならそれらの5割くらいがやりたいことは被害者の救済でなく、上級国民が叩かれること、没落を見て日ごろの留飲を下げたいことなんじゃないかと。
いや、自然だよ。人は自分のために行動するからな。でも被害者を『利用して』加害者の属性を持つ人間を叩く行為は悪だろ。
被害者家族の気持ちとして、今こういう時に世論が石を投げてくれるのは正直なところ「もっとやってくれ」と思うだろう。俺なら思う。
でも時間がたち先方と話したり考えたりするなかで、温度感は変わってくる。世論と温度感がズレてくる。
そうなったとき、当事者である自分を置いてけぼりにして石を投げ続ける人間に疑問がでる。てかイラついてくる。「おめーら関係ないだろ！」って。
でも強くは言えない。自分もかつてそれを望んでいたし、一応「自分たちのために」やってるという建前が向こうにあるから。
温度感がズレれば矛先を変えるのは早い。「お前らだけの問題じゃない！」「お前が良ければいいって話じゃない！」「言いくるめられた！」「鈍感なんだ！」
果ては被害者叩きに到達する。（そういやこの前性別確認インタビューとかあったな）
俺は、復讐ってのは正しい感情だと思ってる。例えば今被害者家族が運転手を殺しても、それは罪だが、悪ではないと思う。（そして罪だから償う必要がある）
だが何かに便乗して（ましてや人の死に便乗）、自分の欲求のはけ口に誰かを攻撃したりすることは、悪だと思っている。
そういう攻撃をすることを、俺は悪だと思うから、それをやめて、再発防止の議論をしてほしいと思うんだ。被害者のためって言うなら、すべきはそれじゃないか。
攻撃にくらべてこれは面倒くさいし欲求も満たせない。でも面倒なことをやるなら、それは確かに人のためだと言えるんじゃないか。
SQLアンチパターンではないが、デッドロックについても投げっぱなしのあのSELECT FOR UPDATEの説明はなんなのかね。
1回のトランザクションでupdateを2回発行する場合と1回のSQLで複数行のアップデートをする時はデッドロックのリスクを考慮するってだけで、かなり初心者にはありがたいと思うんだけどね。
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: デッドロックを検出しました
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
外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか？
外部キー貼らなかったことによって、俺はこんな被害だしたぜっての是非教えてほしい。
すぐに思いついたケースは
とかを思いついたがこんなケースで合ってるのか？こんなケースより間違った外部キーの使い方したほうが家に帰れなくなるケースのほうが多いと思うぞ。間違った使い方をしていて、システムが太ってくるとこんなケースが出てくる。
特に下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図を作成する)の為、実装するってのと個人的に同じことだと思っている。
日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。
https://anond.hatelabo.jp/20190205192741
COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。
SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLのコンパイル単位で、それごとにソースファイルが分割される。ひとつのソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLにコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。
で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイル。sedやawkでテキストファイルやCSVファイルを行ごとに処理するのとちょっと似てるけど、COBOLの場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的なデータの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だからUIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。（混乱するから余談だけど、今のCOBOLはSQLを使って普通のRDBにもアクセスできる。ただ使い方としては、RDB→ファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初と最後だけみたいなのが普通）
入出力がファイルだから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグや不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。
データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOLプログラム側、というのがSQLと一番違うところかも。つまり、このデータファイルの構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。
まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行や官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通の大企業は途中でSunとかに置き換えてその後Linuxやクラウドにさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題。
チケットを「そのチケットの何倍もの価値を引き出せる秘密鍵の所有者」に販売することで、転売を防ぐというアイディア。
・1000円のチケットを販売すると、チケットは購入者が持つ「1万円以上が入ったビットコイン・アドレス」に結び付けられる。
・この1万円は特に問題が起きなければ常に購入者の所持しているものであり、デポジットのように一時的に販売者に渡す必要はない。
・チケット購入者は、チケットを利用する際にこのビットコイン・アドレスの秘密鍵を使って送金トランザクションを作成することでチケットを持っていることを証明する。
・その瞬間にビットコイン・アドレスに入っている金額が1万円未満になった場合、そのチケットは無効と判断される。
・これは単に秘密鍵を持っていることの証明なので、その送金トランザクションは実際に処理される必要はなく即座に破棄していい。
１つ目の防止効果は、1000円のチケットを譲渡するときに1万円が引き出せる権利とセットでないとそれを譲渡できなくなるというもの。転売屋はチケットを売った後に客が1万円を持ち逃げするリスクを負う。
２つ目の防止効果は、転売屋から購入したチケットは転売屋がいつでも無効化できるチケットだというもの。転売屋はいつでも1万円を引き出せる秘密鍵を所持しているため、客は購入したチケットが無効になるリスクを負う。
３つ目の防止効果は、1000円のチケットを100枚購入するためには、100万円の価値を持っている必要があるという点。単純に買い占めがしづらくなる。
明確に違法性のあるトランザクションがあって、一刻も早く消さないと深刻な損害があると仮定した時、誰がどう対応するのか、できるのか。色々探したけど見当たらない。
The DAO 事件。
『web3.0ってなんぞ』という方はとりあえず↓など参照しつつ。
【事例で解説】「Web3.0」とは何か？普及するのか？
http://www.ikedahayato.com/20180219/74516919.html
まぁ新しいものに忌避感を感じるのは当たり前だし、Twitterやらを『中央集権的』なんて書くのはひどい印象操作でムカつくって感情的反発もあるけれど、それにしたってこれどうなの？
2）誰にも改竄できないよ
みたいに謳われている辺り。ほんとにござるかぁ？
P2Pの、暗号化された、ブラックボックスな通信が一部のアプリケーションやカード決済時だけでなく広く当たり前になると、もう素人にセキュリティ対策なんてできなくない？ 何処と何を通信してるのか分からないよね。自分の情報を自分で管理できるようになるって謳い文句の逆に聞こえる。何らかの形でプロの助けを得るか、あるいは開き直ってガバガバになるしかないような。
一応は『本人の了承』を取り付けてから個人情報を売り物にする方が幾分マシだと思いますが。
明確に違法性のあるトランザクションがあって、一刻も早く消さないと深刻な損害があると仮定した時、誰がどう対応するのか、できるのか。色々探したけど見当たらない。
仮にそれが、本当の意味で誰にもできないんだとしたら、そんなリスクを抱えたプロトコルは出来損ないだ。
仮にこの叙述が嘘で、『本当は権力者ならごにょごにょできる』としたら、やっぱり出来損ないだ。
ブロックチェーンの解説読めば何処にでも書いてある。『仕組み上、割に合わないから誰もやらない』って。
短期的に損する前提なら出来るんでしょ。金銭が目的じゃなければ。もちろんそれは一般人が気軽にできる範囲ではない設備投資が前提だけども。
できないは嘘。できる。
お金さえあればできる。
ちっとも良いことを書いていないのに、文章上の味付けで良く見せている。現状みつかるweb3.0の解説にはそういう印象を抱いています。
個人的には下記の通り。
上記の業界の商品は、おおよそ同じ金額を払って同じようなパッケージを受け取ることしかできない。
高い金を払ってより高品質なパッケージを手に入れることはできない。
様々な人に自らの作品と触れてほしい、という思いはうれしい。
ただ、俺としては正規の手段でもっと金を払って作り手に報いたい。
それは単にオリジナルの創作者だけではなく、手に届くまでにかかわってくれているすべての人に報いたい。
でもただ金を寄付したいわけじゃない。商取引として妥当だと思う内容なら、という条件付きだ。
同じ商品を無駄に複数買ってゴミを増やすとか、余計な飾りに余計な金を払うという方法じゃなく、
アニメなら高画質高品質で、高い金払えば高品質(今だと4Kかな？)のままローカルにキャッシュしてオフラインでも閲覧可能とか
漫画なら物理本より高い金額を払えばデジタル版も即日DL可能(電子透かしぐらいなら入っててもいい)になるとか、
既存のビジネスと併存してよりメリットのある高額なサービスを提供してくれないものか？
ゲームだと最近は拡張パスがセットで高額で売りに出されるのは一般化してきた。
ちょっと前までは絵画を切り取って売っている画像を掲げてドヤ顔で批判する人たちもいたが
最近はマイクロトランザクションというよりヘイトを集めるサービスが台頭してきたおかげで
ただ、自分にゴミを増やすだけとか余計な飾りとかそういうものに金を払う気はない。
頼むよ、泥棒や乞食を追いかけたって一銭にもなりゃしないんだから俺からちゃんと金を巻き上げる方法を考えてもっと繁盛してくれよ。
より金を払ってでもいいサービスを受けたい人間はちゃんといるよ。
もちろん標準サービスの客より少ないけど、より多くの金をちゃんととれるよ。
これから先労働力は減っていく一方なんだから、理想を掲げてブラックな働き方するの止めて
自分の趣味にすら払う金を削ろうとする連中より、自分の趣味により金を払う連中の意見を尊重してくれよ。
別に前者を無視しろってわけじゃない。今後者をガン無視してるんだからもう少しこっち向いてくれ、っと言ってるだけだ。
物理本の流通経路に悪影響を与えたくないってんなら、DL版と一緒に物理本買うことも厭わないよ。
既存の流通経路でDL版売ってくれたっていいよ。ゲームは実際そうしてるだろ？
