  |
はてなキーワード: データベースとは
ちょっと全国宿泊施設と大手予約システムで協力して信用情報データベース作ろ
クレカの信用情報と運転免許のゴールドくらいの個人情報で信用のあるやつ
宿泊時に施設側に情報開示OKした場合、開示者のみ一律一泊100円値引き、開示結果優良宿泊者であれば『円滑な運営に協力している』ということで宿泊費値引きや素泊まりプランでも朝食券もらえるとか、○円までのアルコールまたはソフトドリンクプレゼントとかコインランドリー無料券とか。施設側で出せる「ちょっと」が分からんのでユーザー目線での「ちょっとお得」案で申し訳ないけど。※割引券(開示者が追加で金出すのが必須のもの)とかもは本質から外れるのでNG
あとはお高いセレブリティなホテルには一般か優良宿泊者しか泊まれないみたいな制限あってもいいと思う
ブラックリスト運用も必要だけど、ホワイトリスト的なこともあっていいと思うんだよね
友人が施設側になるべく迷惑かけないようにチェックの時間守ったり汚れ物やにおい物を持ち込まないようにしたり忘れ物チェックが厳しかったりゴミ箱に入らないゴミは持ち帰ったりする感じの人なので、そういう人が施設側に優遇(歓迎)されるといいなという気持ち
ChatGPTとはてブの人気コメどちらが信用できるか？調べてみた - ふろむだ＠分裂勘違い君劇場
https://fromdusktildawn.hatenablog.com/entry/2024/06/08/073626
ブコメでKnoa がスウェーデンの数字と合致する記事を発見したと報告。
スウェーデン18.5%の資料は発見→ http://www.hhk.jp/senmonbu/seisaku/files/seisaku_shosai091115.pdf
2010年の医療団体の機関紙。スウェーデンの数字のソースは次。
正しくても随分と古いデータだ。
ChatGPTに聞いてみた。
2007年のOECDのデータで、スウェーデンの「総税収に対する消費税収の割合」は18.5％であるという話は事実ですか？調べて回答は日本語で翻訳して書け
ChatGPT
2007年のOECDデータによると、スウェーデンの総税収に対する消費税収の割合は18.5%という情報は事実です。このデータはOECDの税収統計から確認できます (OECD Statistics) (Site homepage) (Site homepage)。
具体的には、消費税（付加価値税（VAT）やその他の間接税を含む）はスウェーデンの総税収の18.5%を占めています。この割合は、消費税が総税収に占める割合として、OECDの他の多くの国々と比較しても標準的な値と言えます。
ChatGPT
最新のスウェーデンの「総税収に対する消費税収の割合」は、約24.1％です。このデータは、OECDの2022年の統計に基づいています。消費税（VAT）は、スウェーデンの財政収入の重要な部分を占めており、その他の税収源と比較してもかなりの割合を占めています (OECD) (OECD Statistics) (OECD)。
この割合は、過去数十年で変動しており、2007年の18.5％から増加しています。この増加は、スウェーデン政府の財政政策や消費税収の増加によるものです。
では日本は？
OECDのデータで、日本の「総税収に対する消費税収の割合」が約37％であった年はありますか？
ChatGPT
OECDのデータによると、日本の「総税収に対する消費税収の割合」が約37％であった年は存在しません。日本の消費税収の割合は通常約20％前後で推移しています (OECD) (Site homepage)。例えば、2021年のデータでは、日本の総税収に占める消費税収の割合は約25％でした (OECD Statistics)。
これは日本の税収構造の一部として、消費税が他の税収源と比較して特に高い割合を占めることはないことを示しています。消費税は重要な税収源ですが、所得税や法人税など他の税収も総税収に大きく寄与しています。
もしさらに具体的なデータや詳細をお知りになりたい場合は、OECDの公式データベースや関連する統計レポートを参照することをお勧めします。
これらChatGPTが正しいかチェックするのは自分の頭では面倒くさいのでしてない。37%が何の数字なのか気になる。
自分もふろむだと同じように、この人の言ってることのネタ元は（たとえ事実として間違っていたとしても）何なんだろう、ということを考えてしまうタイプ。「海外でなんちゃらと報じられていて衝撃」なんてエントリがあったら海外の元ソースまで追いかける。
汝増田に更なる娯楽を教えよう
登記簿は土地建物の所有権の変遷や抵当権といった担保権の内容が記載されている。
いつ、売買や贈与、相続を原因として、誰から誰に所有権が移転していったのかを把握できる。
照会に必要なのは、地番だ。2丁目3番4号のような家屋表示ではなく、1234番地みたいなやつだ。
古い戸籍謄本の本籍地がそのまんまそれにあたるといってよく、本家の遠戚の土地建物の変遷を目にすることができるかもしれない。
最近は1件600円とやや高い。ワイは公営の登記情報提供サービスを頻用している。
初回登録は難儀だけどクレカ決済で土日でも夜中でも全国の登記簿を取れるので便利だ。
これを面白いと感じたなら、オンラインでは取れない、電子化される以前の登記簿を法務局窓口で取ってみるといい。
国会図書館が膨大な資料をテキスト検索できる形でデータベース化している。
そのうえ画面で高画質スキャンデータを閲覧できるし、わずかな費用で印刷して郵送までしてくれる。
その規模はなかなか驚異的で、ワイの遠戚の爺さんが5歳ごろの1950年代に児童雑誌に投稿した内容まで発見できた。
まだまだ楽しみは続くぞ。
厚生労働省は通知関係をデータベースで全文検索できるようにしていて国の役所の中では比較的ましな方なんだけど、
こんなふうに重要通知をスキャンデータを掲載してるだけのケースも山ほどあるんよ。なんとかしてくれよ
https://www.mhlw.go.jp/web/t_doc?dataId=00tc1901&dataType=1&pageNo=1
一応市町村向けの専用ポータルみたいのはあってpdfで取得出来たりはするけど、改正の新旧対照表だけのっけて
改正を反映した溶け込み後の通知や条文がついてないとかザラなんよ。頼むよ。
おまえのパソコンの一太郎ファイルをそのまま載せればええんよ。
あと保育関係な。通知の名称で検索するとGoogleさんがpdfファイルへの直リンを示してくれるけど、
おおもとのhtmlでのページが見つからないもんだから、そのpdfが時系列的に最新なのかわからないのよ。
マチアプで知り合った女性からLINEが来て、ある大手の結婚相談所連盟の個人経営の結婚相談所に入ったと。
で、入って後悔したと言ってる。
60人申し込んで返事ゼロ。
離婚歴はある。
本当は薬がないと生きていけない程に重度だが、全く書いていない。
機微情報とは言え、重大な持病を隠して婚活する女性には正直懸念しかない。
というか、キツい言い方かもしれないけど、
お見合した相手が重い病気を実は持っていてそれを全く最初から言わないなんて、欺しなんだけど。
で、ある時、その女性が通話したいと言うから通話してあげたのだけど、
相談所の話をしていたら、自分から結婚相談所の話題を出したのに「もうその話はしたくない」と言うし、
離婚した旦那の話題を自分から出したのに、「旦那の話はしないでくれる？」と言うし、
とにかく、わがままだ。
自分は何も相手に提供できないのに、元夫は年収700万だったから、次の相手も年収700万以上が希望と言う。
ただ、その元夫は残業・休日出勤が非常に多く、管理職でもあったらしい。
そんな発想をする人は初めて出会った。
相談所の質が悪ければ、こういう、言うと本当に悪いけれど、質の悪い会員が来るんだなと思って。
お見合申込は、会員→会員に直接届くのではなく、
会員 → 自分の担当カウンセラー → 相手方カウンセラー → 会員
のようにカウンセラーを経由して届く。
必ずしもプロフィールに条件が全て書かれているわけではない。
年収800万以上だと思っていても、わざわざプロフに書くのは下心が見えすぎだから、こうはって事前にフィルタリングするのだ。
で、何が言いたいかと言うと、このフィルタリングの仕組みのことで、
質の悪い相談所や、相手方カウンセラーが予め把握している微妙な会員を排除する仕組みがあること。
30kg痩せた増田だけど、バズって絡まれるのがいやなので別記事でひっそりとオレ式ダイエット法をまとめるよ。
こんなこといちいち言いたくないんだけど、ダイエットに万人の正解なんてないのであくまで増田に効いた方法だし、逆に、だからこそ一般論で否定されても知らねーよとしか言いようがないのでめんどくせーのは絡んでくるなと釘を指しておくよ。
この記事では「正しいダイエット」とされるものをことごとく否定していくよ。
増田が体質改善と四六時中の体重計測を通して理解したのは、ちゃんとカロリー消費ができれば毎日必ず100gは寝起きに（トイレのあとに）減っていること。
そして増田のような在宅ワーカーがきちんと体重を落とせるレベルのカロリーって、ものすごく少ない。増田の場合はせいぜい1000kcalくらいで十分だった。
糖質制限で脂質は取っても良いって言われたけど、脂質も結局は調理油くらいしか使わないのがベストだった。
毎日食べてたオムレツに、バターをたっぷり使ってたんで十分だったみたい。
タンパク質や食物繊維の量だけ考えて、後は体重が減らないならどこまでも減らして構わないと思うよ。
体重は寝ないと落ちない。寝ている間に脂肪を燃やしているのか、単に脂肪燃焼後の水分排出まで回らないだけかは知らないけど、体重は寝起きのトイレ後で計るのが一番。
この時に前の日より減ってなかったら、とりあえず水を飲むなりして様子を見る。
きちんとカロリー制限ができていると、少ししてからちゃんと大量の水分が出て体重が減っている。
このタイミングで出てなければその日は失敗と思って良い。
昼寝も重要。とにかくストレスが高いと脂肪は燃えない。下手な運動より昼寝。
バランスよくなんでも食べようとかいう雑な栄養論に騙されない。
上でも触れたように、最低限はタンパク質と食物繊維だけ計算してれば良い。
ビタミンやミネラルって、増田は文科相の食品成分データベースで徹底的に調べたけど、言うほど「○○の多い食品」を気にする必要はない。
脂溶性ビタミンは肉卵を食べてれば何となく取れてるし、水溶性ビタミンも肉卵を食べていればB群が、野菜を食べていればCが普通に取れている。
つまり肉卵野菜（葉物）を食べてればビタミンに問題が出ることはない。
これに問題が出るのは、むしろ「胸肉ばっか食え」とかいううるさ方のダイエット。肉は脂肪分も気にせず食べよう。
ミネラル分はちょっと難しいけど、サプリでも飲んでおけば良いじゃん。もともと植物の吸い上げた土壌の成分なんだから、粉で飲んどけ。
増田は難しいことを考えずに、最低限のルールだけで後は自分の体に聞きながら痩せていくダイエットに成功。
これの何が良いかっていうと、体質とか考え方が完全に変わったってことだよね。
よく「太る人の思考回路」「痩せてる人の思考回路」の対比ってネタがあるけど、あれの両側の気分が理解できる。今は完全に痩せてる思考回路になったから。
よく言われるような「正しいダイエット」のルールに縛られてると、理屈で自分をねじ伏せてるだけで、本当に痩せる考え方というものは身に付かない。
デブはまず「平気なレベルの空腹」がどれだけ痩せてる人と違うのかを知ることが大事。
来た来たｗ
わざわざ釘を刺してるのに、「それは間違ってる」の大合唱ｗ 間違ってるなら結果は出ないんだよｗ 科学的に物を言えｗ
いきなり本格的な広告管理ツールを作るためにデータベース設計するのではなく、最初は簡易的なプレーンテキスト形式の設定ファイルで管理するところから始める。
そうすれば当面の間はその簡易機能で対応できるし、対応の速度も早い。
広告管理のスケールが大きくなってきたと感じたところで広告管理のCRUDを設計するのでも遅くはない。
ただし、このアプローチを採用する際には、将来的にデータベースに移行することを見越した設計をすることが重要。
具体的には、設定ファイルの形式を選択する際には、データベースに容易にインポートできる形式を選ぶこと、また、データの整合性を保つための適切なバリデーションルールを設けることなど。
世の中にはウンコのようなシステムがあるが、その最たるものとしては複数のアプリケーションでDBを共有するものだ。
まさに今取り組んでいるプロジェクトがその典型例だ。データの一貫性や整合性がとれないようなシステムはおむつに包んで汚物入れにいれるべきだ。
DBを複数のアプリケーションから共有するな。これだけのことを何度言わせるのか。
上記の問題を解決するために、他のソリューションを導入したりする。
ちがう、そこじゃないんだ。データはアプリケーションで閉じろって話だ。
根本的な問題は、要求事項から最適なシステムを作る人の不在だ。
REST APIの設計も酷いもので、エンドポイントがDBのテーブルそのままを表しており、トランザクションもクソもない。
APIがデータベースの構造に過度に依存しており、データベースの変更が直接APIの修正に繋がる。このため、些細な変更でも広範囲に影響が及ぶことになる。
https://anond.hatelabo.jp/20240507125309
はい。
ではなく、SQLは処理じゃなく、定義であることを理解するのが大切。
何の定義かと言えば、リレーショナルデータモデルへの演算定義なんだよ。この演算には、関係代数という演算を使う。
なぜ定義だと認識する必要があるかという、Selectは出力でも何でもなく、射影という演算の一部なんだよ。
"+3" とかと一緒
で、関係代数演算は順位にもちろん意味がある。最初に"射影"して"選択"かけたら全く別になる。
SQLは、この演算順位を、SelectやWhereの中で状況によって意味が変わる。という出鱈目なカバーで逃げた。Order byで悩んだろ。
さらに言えば、苦肉の策でWhereのパチモンはどうしても2回必要でHavingを作ったのよ
本来で言えば、この演算は、選択-結合-射影-結合といくらでも出来る。
「足し算は頭に一回書いてください。複数使う時はかっこつけて下さい。ちなみに、掛算を一緒に使うと足し算の意味が変わり場合によってはエラーです」みたいな安直な構造定義しちゃってるの。
リレーショナルモデルへの演算としてだダサダサで、リレーショナルモデルの演算の複雑さではなくSQLという表現の都合で人類の頭に負荷かけ続けてる。
出力が頭にあるのは便利(間違い)。英語だから(間違い)。って言われると何言ってるんだーって、ちょい昔のまともなデータベースエンジニアなら普通にキレてた案件
漫画を追いかけるにはプログラミングも勉強しないといけないみたいな考えになる。
bookliveとかで、登録されている作品を全て一括表示するとそれはそれは何十万件と出るわけだ。
一個一個ざっと見でもサムネを確認して大雑把に内容を確認する、そのなかから気になったものをジャケ読みするという方針をとるにしても、しらみ潰しにそれを行うにはネットワークやデータベースの挙動に関する知識が必要だと知る。
これはブラウザ履歴にキーワードが反映された検索結果のURLがあってそこからダイレクトにアクセスしても検索結果が表示されることからも明らかだ。
これは裏を返せば、たとえば８時丁度に検索結果1ページ目を表示してから何秒か経って一通り見てから2ページ目を表示した場合と、同じ８時丁度に最初から2ページ目を表示するのとではそのページの検索結果としての構成が微妙でも異なる可能性があることを示している。
1ページに100件漫画を表示する仕様を採用していて検索結果が2000ページだとしよう。ソートは仮に人気順だとする。まあこれはしらみ潰しするうえでは絶対選んじゃいけないソート法なんだけど。
1ページ目を表示したその瞬間に、5ページ目に表示されるようになっている漫画があったとしても、5ページ目を表示したころには1ページ目とか4ページ目に表示されるようになってるかもしれない。普通に順番に次々ページを進めていって5ページ目に到達したときにはこのことに気づかないかもしれない。以降やっとの思いで2000ページ分確認を完了しても、ついにその漫画を確認する事なくしらみ潰しできた気になってしまい得る。
二周すればいいと思うかもしれないが原理上何周しようが同じように1ページ目に表示されなくてスルーしてたら2ページ目を表示したときには1ページ目に表示順位が変わっていたりして、結局「入れ違い」になり得る。
今のような具体的な話を聞いていると「別タブに1ページ目を表示しておいてじゃあページを進めるたびに1ページ目の表示を更新する定点観測をすればいいじゃん」と浅い考えを持つ人がいるかもしれないが、こうした順位の変動は2000ページの範囲のあらゆるページとページの間で起こりうることなので、そうした考えは全く通用しないことは、少しでもアルゴリズム的な思考を駆使できれば理解できる事だと思う。
最低でも新着順じゃなければならない。新着順にした上で1ページ目を定点観測。ページ進めているときに1ページ目の表示が変動したら、プルプッシュ？式の考え方なら直前に見たページにあったいくつかのデータが今のページに追いやられていることに注意すればいい。しかしこれで果たして完璧なのか？プログラマー的センスがまだまだ足りなすぎて盲点はないか（実際いずれは自動化を検討しているのでもろプログラミング技術の学びが必要）？Code CompleteとかClean Architectureとか読まなきゃだめちゃう?みたいなことを考えてしまう。
でもいざ漫画の造詣が深い人で「こういうことを難しく考えて」プログラミング身につけたしプログラミングが役に立った漫画オタクのきょうようだなんて言ってる人聞かないし、自分が考えていることの力点ずれてるだけでもっと気楽に生きるべきって気がしてしまう。
はい、JavaScriptによるコーディングはコンピュータサイエンスの一部と見なすことができます。コンピュータサイエンスは、情報とその処理に関する学問であり、プログラミングはその重要な要素です。JavaScriptは、ウェブページを動的にするための主要な言語の1つであり、ウェブ開発の分野で広く使用されています。したがって、JavaScriptを学び、それを使用してコードを書くことは、コンピュータサイエンスの実践的な応用の一部と言えます。しかし、コンピュータサイエンスはプログラミングだけではなく、アルゴリズム、データ構造、ネットワーク、データベース、人工知能など、より広範なトピックをカバーしています。それぞれが特定のプログラミング言語やツールを使用して探求されることがあります。JavaScriptはその一部であり、特定の問題を解決するためのツールとして使用されます。それはコンピュータサイエンスの一部であり、その全体ではありません。それでも、JavaScriptをマスターすることは、コンピュータサイエンスの重要なスキルを習得するための素晴らしいステップです。それはあなたが複雑な問題を解決するためのロジックとアルゴリズムを理解するのを助け、あなたの思考を開発するのを助けます。それはまた、あなたがウェブ開発の世界に足を踏み入れ、あなた自身のウェブサイトやアプリケーションを作成するのを助けます。だから、はい、JavaScriptによるコーディングは確かにコンピュータサイエンスの一部です！
プロットライブラリ、データフレームライブラリ、データベース、などが集計関数を用意している。
例えばある場所ではプロットライブラリの集計を使っているが、別の場所ではデータベースで集計してからプロットするということがあるだろう。
各ライブラリが内部でどういう処理をしているかがブラックボックスであるため、これは問題である。
ライブラリの集計関数を使う場合、テスト用のデータを用意しておき、集計値が一致するかを確認するのがまず必要。
次に集計方法はバラバラでなく揃える必要がある。プロットライブラリに集計させるより、データフレームに集計させてそれをプロットしたほうが良い。
またデータフレームにおいても、groupbyとpivot_tableで集計の扱いに差があったりする。
これらの差が生じる一つの理由はNullやdatetimeに対する処理の違いだったりする。
暗黙の集計に対応するのは大変なので、テストデータに対する集計が正しいバリエーションを選び、その方法で全部揃えたほうが良い。
