「RDB」を含む日記 RSS

はてなキーワード: RDBとは

2021-06-06

anond:20210606064510

データベースを手習いに作りたい人を想定していました(Webサイトを作りたいのならもちろん既製RDBを使った方が良い)

anond:20210606062128

内容自体同意するけれど、データベースの例えは完全に学習方法が間違っていて、データベースを再実装するならデータベース教科書を見ながら現代的なRDB模倣して作るのが一番勉強になる。

自分試行錯誤していくよりも過去の人が考え抜いたものを学ぶ方が勉強になるし、それを自分で書くことで既存DBへの深い理解も得られる。

2021-05-21

増田に聞きたい!スバリ、テック系は次は何が来ると思う?

当方機械学習深層学習に乗り遅れた(自称フルスタックエンジニアであるプログラム言語Java, PHP, Python, Ruby, C, Swift, Kotlin, JS, Rust 何でも好きだ。HTML/CSSSQL も大好きだ。ところが、計算機科学という領域で次に何が来るかわからないので、増田集合知に教えてもらいたい。最近ワードは、以下の感じ。

ブロックチェーン

この手の分散データベースは好きになれない。遅いし。それに、反社会的勢力が暗躍する領域は嫌い。

DX

どうせ、ICTユビキタスとかと一緒で経産省のオママゴトになるのは見えているので、反吐が出る。

人工知能

計算機演算機能が未だに不足しているので、汎用 AI なんて無理なのがわかっているはずだが、何故に人の出入りが激しい。統計的機械学習といったアルゴリズムとして利用する分には、現実的だと思うが。

NewSQL

良いと思うが、既存RDB なんかで十分という気持ちがしないわけではない。

フロントエンドエンジニア

デザイン領域以外は、既存プログラマ延長でしょう?デザインちょっとやる気ない。

UI/UX

デザイナーに頑張ってもらいたい。というか、デザイナーはここは責任持ってくれ。仕事なくなるぞ。

クラウド

いつもお世話になってます

競技プログラミング

世の中の問題に全て答えがあると思っている大馬鹿者の集まり悪趣味

セキュリティ/テスター/Ops/SRE

いきなりセキュリティとかテストとか運用系に行くやつの末路は暗いと思っている。プログラマが後々コンバートするので十分だろ。

追記

AR

俺は好きやけどね。

ガートナー

最近既存ネタを深くするだけじゃね?

2021-05-12

Excel玄人素人を見分ける方法

テーブル化しているかどうか」

これだけ

テーブル化ってなに?」って人は残念ながら素人の部類に入る

追記

玄人

excel上でSQLクエリを使わない人はモグリ

RDBっぽく使うテクニック勘違いしてる素人チラホラおるな

・PowerQueryはちょっとかいデータ食わせるとすぐフリーズする、DAXもPBIに比べていまいち使いづらい。

・スピルを使いこなせる人かなぁ

玄人

・PowerQueryを使いこなせるやつが職場に1人いたらなあ。

・お前みたいなACCESSEXCELの使い分けができない人間迷惑

・まずはリスト形式作成してピボットマトリクス化するのが文明

・ピボットテーブル化するようになってからが本番

Access使ったほうがいいのでは

行列に貼り付けたデータ範囲からSQLで柔軟にデータ抜き出せるような技でもあるの? 

https://www.soumu.go.jp/main_content/000723697.pdf ←これをちゃん理解しつつ実行できてるか、は結構重要

素人

・INDIRECT関数 rowやらmatchやら数値を返す系の関数をうまく扱えるようになると玄人感出せる

テーブル化はせずテーブル形式で表組みする方が玄人

テーブル化、シートが多いブックで参照が飛び交う場合命名ルールちゃんと整理するかCtrl+[ のショトカを活用するかしないと、ここで参照してるテーブルどのシートだっけ?が多発するぞい

普通テーブル使った記憶が無い、大体ピボット

・昔はVBAが使えれば玄人ってイメージがあった

素人

テーブルとか言って、今あるデータを見映え加工してる帳票屋を自負すること自体がもうね。

テーブル化という言葉を知らなかったから知られてみたら、普通にいつも使っている方法だった。GUIだとわざわざその動作名前を知らなくても良いのが魅力ね。

・整然データになってるならテーブル化してるかしてないかは正直どうでもいい

テーブル化は分かる(されてるの見てイライラする)

テーブル化は汎用性無くなるので嫌い。ピボットテーブルもっと酷い。

テーブル化を知った人々、それほどデータもないしょうもないリストまでテーブル化し始めるので、「おぉ、こいつは金槌を手に入れたのだな」って気持ちになる

ポリネシアあたりの未開の土人

・AXCELがどうしたって?

エクセル・サーガ

別の意味でド玄人

Excelにもバージョンがあるけど

文書excelで作るやつは全員素人でいいだろ。

Excel玄人って給料安そう

Excelテーブルについて解説している記事広告が机ばっかりで笑った。

重要データExcelで扱わないこと。。。

Excel玄人になんてなりたくないよ…

2021-05-03

DDDリポジトリってファットにならない?

リポジトリは集約ルートのみ返す。1つの集約にはリポジトリは1つ。リポジトリの中でのみRDBへ問い合わせる。」って書いてあるけど、集約内の関連テーブルへの問い合わせをすべてリポジトリ書くからリポジトリが巨大にならない?

DDD実装例を見ているんだけど、参照はリポジトリ以外からも呼んでいてクソワロタ

https://qiita.com/haazime/items/5776e4e25b6527b682e7

ActiveRecordのassosociationとRepositoryの相性って良くない気がする。(Repositoryのセオリーに完全に従うとassosociationが使えなくなるのでは?)

2021-02-14

16年間続けてきたBlogも移行失敗で1からなんだなぁとおもうとRDBも弱いな

2020-12-31

社長が死んだ

2020年最後の日だし吐き出したかった。

社長の死因は急性心筋梗塞だった。

何事もなければ社長が死んだショックだけで終わったかもしれない。

ただ、自分の中ではもやもやが残ってしまった。

7Payと言えばわかるだろうか。詳しくは書けないのだけど、あれと似たようなことが起きてしまった。

社長上司含め、お客さんに平謝りだったらしい。

かなりのストレスだったと思う。ネットで調べたところ、急性心筋梗塞ストレスでも発症することがあるらしく、そこが少し引っかかってしまった。


様々な理由から現状社長訃報を知らせるページを検索エンジンインデックスされないようにしています

もし心当たりのある会社があった場合でもリンクは貼らないでいただけますようよろしくお願いします。

今回謝る事態になってしまった件について技術的?に思ったこ

使うのであれば、ライブラリフレームワークミドルウェア更新バグ脆弱性情報)を一生追い続ける覚悟で使ってほしい。


テスト自動化とかそういう発展的なものではなく、もっと根本的なテストについて勉強してほしい。

コードレベルカバレッジとかそういうのではなく、「境界分析」、「デシジョンテーブル」、「オールペア法」、「直交表」こういう物について勉強してほしい。

他にもいろんな手法はあるのだけど、上記に上げたもので1個でも知らない単語があった人は今すぐ検索してほしい。


  • お客さんに嘘をつかないでほしい

いくら進捗が悪いからと言ってお客さんに順調などと嘘をつかないで欲しい。

遅れている理由を正直に言って(例えばテスト工数が膨れているとか)相談すればお客さんもわかってくれるかもしれない。

また、テストの質もそこまでの物が求められていないとかがわかるかもしれない。

お客さんに相談しないで工数圧縮の為にろくなテストも書かないで動いてるからいい!っていうのは危ない。


自信がない、もしくは、やったことがない・使ったことがない、などは正直に話してほしい。

しかしたらそのせいで給料があがらなかったり、出世できなくなったりするかもしれない。

だけれど、その嘘のせいで他の誰かに負担がかかったり、他の誰かが不幸になるようなことがあってはいけないと思う。

これに関してはいろんな批判があることは覚悟している。嘘をついてでもいろんな経験をした方がいいって言う人もいると思う。

それでも、どうしても書きたかった。


別にLPIC(LinC)は持ってなくてもいい。本屋適当対策本をパラパラめくって、聞いたことのない単語がないレベルであればいい。


インターネットには嘘が散りばめられている。昔は本当だったけど今は嘘になっているものだってある。

一番いいのはエラーメッセージを出している物のソースコードを読むこと。二番目はドキュメントを読むこと。それでもわからない時だけ検索してほしい。

そして、その情報が誰が書いているかをよく見てほしい。書いている人が本当に信用できる、かつ、更新日付が近かったときだけそこの内容を信じてほしい。


ApacheのC10K問題

公開リポジトリpush/commitされているメールアドレス収集している人がいるということ、

公開リポジトリpush/commitされている秘密情報収集している人がいるということ、

MySQL寿司ビール問題

MacOS日本語ファイル問題

文字サロゲートペアについて、

RDBによってはSQLのIN句に指定できる数に上限があること、


他にもいろいろあるが、1個でも知らないものがあった人は検索してみて欲しい。業界にもよるかもしれないが、本来であれば最低限知っておかなければいけない知識

これを知らないと適切な設計、ましてや適切なコーディングすらできなくなる。

終わりに

ぼくはエンジニアに向いてない

2020-12-25

anond:20201224204327

あっしもそんなに詳しいわけでは無いが、いくらなんでもはてな検索システム一般的全文検索から大きく外れた思想で作られているとは思えない。

まずもって検索システムつうのはどういうものかというと、通常のRDBの通常の検索の話だと、表の特定の列のデータ対象データがあったらその行を返すっつうものだ。

COL1COL2COL3
春麗回し蹴り
サガットタイガーアッパーカット
ベガキャミィグヘヘ
キャプテン沢田キャミィ澤田スペシャル'95

これでCOL2に索引をつけた場合検索条件に「隆」を入れたら行1と行2が返るつうのな。

全文検索だとちょっと面倒でこのCOL1とかCOL2に入るデータが「アストラギウス銀河を真っぷたつに分けた、バララントギルガメスの二つの星系が砲火を交えて、100年。」とかになるわけなのよね。

となると検索する人は「アストラギウス銀河」とか「バララント」とかで検索するわけで、それを想定して分割した「トークン」つう単位単語的なもので分割して索引を作るわけ。

そのトークン分割のやり方がいろいろあってそれで索引の出来方がかわって検索の使い勝手が変わってくる訳なんだけど、日本語場合、まず「てにおは」とかの「ストップワード」で分割して、それぞれのトークンをそれぞれ分割する・・・みたいなのは一般的なのね。

上の文章だと「アストラギウス銀河」 「真っぷたつ」「分けた」みたいに分割して、更に「アス」「アスト」「アストラ「スト」「ストラ」・・・みたいな。

もちろん索引サイズバカみたいになって全部スキャンした方がはやいやんけみたいになったら馬鹿馬鹿しいのでどのくらいのトークンを作るかはさじ加減なんだが、普通の仕組みなら「回し蹴り」はトークンとして入るので元記事の指摘はちょっと違うと思うのだ。

2020-10-30

NoSQLからRDBの移行って無理じゃね?

たまにfirebaseとかでサクッと作って

サービス軌道にのったらRDBにすればいいとか言うやついるけど

全然スキームが違うのにどうやって移行するつもりなんだろ?

本当にこいつら触ったことあるのか?

2020-10-03

anond:20201003213855

仰ることはわかりますよ。フレームワークを使いこなしているだけで、言語理論を知った気になっているという指摘はわかります

しかしながら現実問題、大多数が使っているフレームワークを使わないと CSRFSQL インジェクションといった脆弱性に対して低コストで応対できる方法がありますか?まさか WAF でどうにかなるなんて、言いませんよね。今どきフルスクラッチアプリ作れ、なんて逆に技術力がないとしか聞こえませんが。

ぶっちゃけ RubyPHP なんて、クライアントサーバデータを低コストで受け渡すだけのツールしか思ってないわ。RDB や S3 といったドメインストレージにより近いなにかだし、iOS/Android/ブラウザたかSwift/Java/HTML+CSS+JavaScript をいじるだけじゃねーか。ウェブ領域セキュリティ気にしないと死ぬから、むしろメンテされているフレームワーク更新し続けないと死ぬんだよ。自作メンテしてないフレームワークを利用する方が気がふれているとしか思えませんがね。

2020-10-02

anond:20201002171601

ゲームするだけなら、ログインしたユーザと、そのユーザに関連したデータだけあれば良さそうだが

中央では、ユーザを跨いだシステム全体のデータ検索したり、集計したりする必要がある

そうすると、JSONファイルでは厳しいので、SQLなどを使う

ちなみに無料SQLもある

細かくいうとSQLが使えるデータベース=RDB

無料で使えるRDB=MySQLPostgreSQLなど

2020-08-01

anond:20200731155404

RDBから頭が離れられない人?

増田が言う一般的実装を依頼したら、変なオリジナリティ出されてセンス無い例みたいにしたなら、まあ同意できる

結局のところメモリに展開した時に使いやすければ良いわけで、データ構造で気になるのは行と列を一つの値にしてるくらい

2020-07-31

https://anond.hatelabo.jp/20200731155404

データスキーマデータのものを別々に定義すると便利っていうの、RDB経験なしに「センス」でたどり着いたら天才的だと思うんだけど

増田はてブ天才揃いで凄いわ

2020-07-18

anond:20200718061758

前のゲームテキストファイル管理してましたがRDBでやるなら、たぶん項目がひとつずつ増える事が多かったので、わざわざ別テーブルにせずに、alter tableをしてたと思います

RDB検討した際にテーブル分割などを考えましたが、アップデート仕様がAになるかBになるかわからない時点で正規化は無理だと断念したのを思い出しました。

作り直すのは途中で何度も考えましたが僕の性格では全部消して作り直すのは非常に難しいように感じます

作り直せる人ってすごいですね。思い切りが大事なんでしょうか。。。

anond:20200718044903

最初質問を見たときから普通にidjoinしてるだけじゃないのって思った

RDBを使って作ってあって、新しいtableが参照したいテーブルidを持つようにしておけばjoinで全部の要素を持った大きなテーブルがあるかのように扱えるよね。

気ままにそういう運用をしてきたらjoinによるオーバーヘッドがばかにならなくなってきたり、テーブル間の関係が複雑になりすぎて訳が分からなくなってくると思うので、そういう時はいったん開発を止めてリファクタリングするべきだろうね。

個人的には開発がある程度進んだ段階で全体を俯瞰してご破算で願いましてはして作り直すのもそんなに嫌いじゃない。

ゲーム作りの相談

高校生です。寝る前に面白いゲームを思い付いたのでどうやって作ろうか考えていたらこんな時間になってしまいました。

沢山のモンスターが出てきて、それを集める要素があるのですが、このモンスターデータをどう管理するのが良いのか、さっぱりわかりません。

識者の方、お力を貸して下さい。

相談内容を簡単に言うと「仕様が固まっていないゲームモンスターデータをどう管理するか」です。

まず、ゲームは小さく作りたいので、モンスターデータも最小限になるのですが、もしヒットしたらどんどん要素を追加したいのです。

最初モンスターの数も100ぐらいですが、ゲーム寿命を伸ばしたいので、数千ぐらいまで増やせるのが理想です。

そして、ここが肝心なのですが、ユーザーの反応を見ながら仕様を変えたいので、どんなデータ必要になるのかは、究極的にはサービスが終了する時までわからない、という事です。

年の離れた兄に相談したら「それって昔流行ったパズドラみたいだね」と言われました。話を聞くと確かにそんな感じがします。パズドラ最初から今の形が全て決まっていたとはとても思えませんでした。

(合成とか覚醒スキルとかプラスなどなど、どうみてもあとで思い付きで増えた要素があるように思えます)

なので、この質問パズドラぐらい大ヒットさせたいという野望があるゲームモンスターデータ最初期にどう設計するか?と言い換えることもできるのかもしれません。

以前に似たゲームを作った時に困ったのは、例えば

id, 名前, hp, mp

みたいにデータがあるとすると、あとでモンスター進化させようとして、進化id という項目を付け足したり、そもそもid っているの?表の上から順番に何個目かってのをid にしたら良くない?と思ってid を削除したり、

などとやっているうちに、コードがぐちゃぐちゃになりました。

どんな追加要素がきても柔軟に対応できて、コードがぐちゃぐちゃにならないようにするにはどうすれば良いのでしょうか?

モンスター進化させる素材(モンスター自体が素材になる事もあり得る)なんかはモンスターデータと同じものとして管理するのが良いのか、別のものとして管理するのが良いのかもわかりません。

テキストファイル管理したら良いのか、RDBなどで管理する方が良いのかも判断できません。

2020-01-08

無印良品ウェブサイトが止まってる件について思うこと

この件⇒ https://togetter.com/li/1452558

ユニケージbashパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理(だいたいプログラム1本の処理内容がメインフレームCOBOLのそれと同じくSQLクエリ1個に相当する)で、同形式によるマスタとトランザクションファイルRDBMS内部のredoログに相当)を使う(データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバー複数存在するデータ場合どう扱うかは知らない)

開発と更新は早いんだけど参照が(テキストファイルなので)インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう

おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージ実装されていないかもしれないけど、しかし根幹に上記のような手作りデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルマージしてインポートすることになる

追記トランザクションファイルのマスタへのマージ営業時間後の日次バッチとかでやるはず

システムを止めている間も店舗運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない

追記テキストファイルに対するインデクスをつくって行頭へのシーク高速化をすること自体はもちろん一般的には可能だけど、ユニケージ方法論だとそれをする標準的方法はないはず。ユニケージRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合SQLのUPDATE相当)当然行頭のバイト位置が変更した行以降ですべてずれてしま可能性があるのでインデクスの更新がひどく非効率になる

追記文章下手ですみません。ユニケージの良いところはRDBMS実装の基礎を理解できるところ(これはDate先生教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識ちゃんとした教科書で補う必要がある)、アプリケーション実装技術について横断的な理解ができるところだと思います(USP研究所シェルスクリプトマガジンには実際勉強になりそうな記事が多い)自分はユニケージへの移行案件を生き残れなかったクチなので。。

追記:Tsukubaiは好きになれませんでした。

追記anond:20200115152201

2019-05-23

誰か雇ってくれ

SQLJavaScriptExcel VBAVB.NETC#Java。前者ほど触ってる期間が長い。SQLJavaScriptが1年半くらい、Java参考書一冊読んだくらい。

Webで言うとフロントはAngularが少し分かる。サーバーExpressが少し分かる。

RDBテーブル15個くらいの社内向けWebシステムを一人で組んで現在半年以上運用中。今はテーブル40個くらいのシステム組んでるところ。

LinuxUbuntuなら少し分かるけど、Docker周りは手を出したことがない。AWSとかGCPとかも分からない。

実務経験は無いに等しい。独学とプライベートの開発だけでこれまでやって来た。

できれば茨城県南だとありがたい。誰か雇って下さい。

2019-03-24

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-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-10-20

anond:20181020224028

同意

ロック処理とか甘いしサイズ制限も2GBだしANSI SQLに一部対応してないしで、Webサービスバックエンドに向かないのは間違いないが、さりとて5万行程度のテーブルを捌けない程無能RDBでもない。

複数テーブルでもちゃんと外部参照設定して第3正規化するくらいは普通にできる。複数テーブルJoinしたりサブクエリ書いたりもできる。

元の発言した人は、ちゃんAccessを使ったことがあるのか疑問である

ただ、Excelよりも便利なのは確実だが、WordExcelくらいしか使えない人も多いので、ほかの人とデータ共有するのであれば、Excelのままでもいいかな。

2018-08-30

[]2018年8月29日水曜日増田

時間記事文字数文字数平均文字数中央値
008615570181.063
0141295472.040
02152460164.060
03165067316.738
04193688194.163
05541783.422
06648781.239.5
0720149774.935
08345674166.950
09666624100.435.5
10929985108.546
111171020987.350
1211613997120.735.5
13110584453.132
141421268489.339
15145955165.933
16148901160.934
1775639685.335
1816123682147.130
191371271192.842
207510183135.855
211141093895.935.5
221101063696.741
23137827660.432
1日198719854199.939

頻出名詞 ()内の数字単語が含まれ記事

人(179), 自分(134), 話(86), 問題(81), 今(76), 日本(64), 仕事(64), 増田(60), 意味(58), 女(58), 男(55), 必要(50), ー(47), 人間(46), 気(45), 感じ(45), 前(44), 好き(43), 理由(41), 場合(40), あと(39), 相手(38), 子供(37), 関係(36), 存在(35), 金(34), 安倍(33), 他(32), 最近(31), 世界(31), 無理(31), 女性(29), 気持ち(28), 会社(28), 事実(28), 社会(27), 状況(27), レベル(26), しない(26), マイノリティ(26), 結婚(25), ネット(25), 普通(25), 完全(25), 別(25), ただ(25), 子ども(25), じゃなくて(25), 今日(24), 結局(24), 生活(24), 頭(24), 時間(23), 大学(23), 理解(23), 検索(23), 記事(23), 意見(23), お金(22), 絶対(22), 中卒(22), 親(22), 最初(22), ダメ(21), 個人(21), 自体(21), 作品(21), 言葉(21), 昔(20), 正直(20), 確か(20), 目(20), バカ(20), 件(20), 違い(19), 友達(19), 可能性(19), 人生(19), 認識(19), 扱い(19), 嫌(19), 全部(19), 障害者(19), 馬鹿(19), 内容(19), 一番(18), 毎日(18), 差別(18), 手(18), 主張(18), 逆(18), 権力(18), 批判(18), 情報(17), 場所(17), オタク(17), 普段(17), 世の中(17), サービス(17), 結果(16), たくさん(16), 顔(16), html(16), 嫌い(16), 全て(16), 質問(16), マジョリティ(16), 先(16), 現実(16), 平成(16), 家(16), 表現(16), 漫画(16), 日本人(16), マジで(16)

頻出固有名詞 ()内の数字単語が含まれ記事

日本(64), 増田(60), 安倍(33), マイノリティ(26), じゃなくて(25), 障害者(19), 可能性(19), 平成(16), マジで(16), マジョリティ(16), 自民党(15), 低所得(14), アメリカ(12), なんだろう(12), ブコメ(11), PC(11), 元増田(11), 最低賃金(10), 物理法則(10), YES(10), 機械化(10), 二次創作(10), ワイ(10), はてなー(9), ようじょ(9), 健常者(9), 何度(9), 障碍者(9), 普通に(9), 2018年(9), 下方婚(9), な!(9), IT(9), ツイート(9), 米(9), ネトウヨ(8), いない(8), 共産党(8), DL(8), はてブ(8), トラバ(8), s(8), B(8), Google(8), Twitter(8), 関係者(8), ブクマ(7), アプリ(7), 東京(7), 一緒に(7), 自衛隊(7), 娘(7), 基本的(7), わからん(7), キモい(7), 石破(7), 筋トレ(7), twitter(7), 24時間テレビ(7), ブログ(7), SNS(7), にも(6), なのか(6), 発達障害(6), 1人(6), どんだけ(6), 好きな人(6), サーバルちゃん(6), Suica(6), RDB(6), pixiv(6), 真珠湾(6), 単純作業(6), 回転寿司(6), NHK(6), スマホ(6), RDBMS(6), タトゥー(6), 毎日(6), ???(6), 自然法則(6), ツイッター(6), A(6), アベ(5), 一般市民(5), さくらももこ(5), フェミ(5), 1回(5), ちびまる子ちゃん(5), ガチャ(5), ありません(5), ブクマカ(5), 1日(5), Amazon(5), 中国(5), 結果的(5), hatena(5), かな(5), 北朝鮮(5), お客さん(5), 20万(5), ちんこ(5), 障害者雇用(5), いいね(5), 艦これ(5), 2年(5), 被害者(5), 大五郎(5), はてな民(5), 個人的(5), LINE(5), スレ(5), 7%(5), 10人(5), ゴルドー(5), E(5), 民主主義(5), jsfiddle(5), 人間性(5), …。(5), 正義(5), 1割(5), 同人誌(5), 1件(5)

投稿警察もどき日中に再投稿された本文の先頭20文字 ()内の数字投稿された回数

うんち (12), そうだね。うんちだね。💩 (3), パンティー (2), https://jsfiddle.n(2)

頻出トラックバック先(簡易)

世界三大ペンギン /20180829074002(11), ■[ゲーム]クイズ検索したら1件しか出ませんでした /20180829140908(10), ■ /20180829165740(8), ■早稲田大学現代文コースセクシャルハラスメント報告書がひどい /20180828223619(7), ■【思考実験】女はゴルドーを避けるのか? /20180829123815(7), ■なんで漫画実写映画は /20180829112319(7), ■anond20180829183228 /20180829184256(6), ■ /20180829113426(5), ■【緩募コミュニケーション不要仕事急募】 /20180829213909(5), ■外人って寿司おいしいって思うのかな /20180828164004(5), ■沸騰した味噌汁 /20180828153328(5), ■ワイシャツってクリーニングに出す物なの? /20180828221836(5), ■揚げ物 /20180829141503(5), ■anond20180829154129 /20180829154559(5), ■増田って /20180829004704(5), ■娘ちゃんとうんち /20180829125723(5), ■お見合いするべきか? /20180829205310(5), ■保護猫さんを飼いたい /20180829081201(5), ■ナンパは軽薄で犯罪的な行為なのか? /20180829222920(4), ■anond20180829185836 /20180829190637(4), ■ /20180829121011(4), ■はてな民繊細チンピラ多すぎ問題 /20180829125728(4), ■卵かけご飯 /20180829122540(4), ■ネット上の艦これコミュニティまとめ /20180829031342(4), ■ /20180829111343(4), ■平成が終わる という表現 /20180828120344(4), ■日本人の字幕への意識の低さは何なん? /20180829155850(4), ■anond20180829182954 /20180829183228(4), ■筋肉っていつからブームになったの? /20180828201927(4), ■はてな民Vtuber知識ガバガバ /20180829162352(4), ■anond20180829161508 /20180829161634(4), ■風邪幼女って効果あるの? /20180829094551(4), ■ /20180829140907(4), ■いい歳してコンビニ立ち読みしてるおっさん /20180829083418(4), ■24時間テレビを叩いている方へのお礼 /20180829112304(4), ■フリーアーチャーにならなきゃよかった /20180828115851(4)

増田合計ブックマーク数 ()内の数字は1日の増減

5555667(3158)

ログイン ユーザー登録
ようこそ ゲスト さん