SQLなら俺に訊け [無断転載禁止]©2ch.net (457ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
88(1): デフォルトの名無しさん [sage] 2019/01/04(金) 14:11:21.43 ID:HolJeFBP(1) AAS
ORM求める輩って何なんだろうなSQL書けよ
107(1): デフォルトの名無しさん [] 2020/12/17(木) 13:35:51.43 ID:rhbff53i(1/2) AAS
MySQLで時間を管理し、一定時間過ぎたら、
レコードをの情報を更新したいのですが、
どの様にすればできるか教えてください。
1. このようなことがMySQL単体で可能なことなのかな？
2. 可能な場合どのようにすれば実現できるの？
イメージとしてはこんな感じです。
開始時のレコード001
ID, 開始 , 終了
001, 13:00 , 13:30 ← 13:00に開始
↓ 30分経過後（同一レコードの動き（自動更新））
終了時のレコード001
ID, 開始 , 終了
001, 0 , 0 ← 13:30になったからクリア
115(1): デフォルトの名無しさん [sage] 2021/01/19(火) 00:28:07.43 ID:hiZmhE+d(1/2) AAS
>>114なるほど。さんくす。
ついでに、Rubyでユーザー登録や認証をした結果をMySQLの中に
データとして貯めるようなサーバーサイドのCGIのライブラリ
みたいなものは有る？
180: デフォルトの名無しさん [] 2022/06/22(水) 21:18:18.43 ID:JRkIVgOU(1) AAS
>>177177(1): デフォルトの名無しさん [sage] 2022/06/14(火) 16:44:05.01 ID:eTPeyH+k(2/2) AAS
>>176 ありがとうございます。
しかしながら
テーブル名 IDの最大値
テーブル1 6
テーブル2 1014
テーブル3 1990
テーブル4 74
テーブル5 1861
テーブル6 136
という感じに表示されてほしいです
それなら統計情報を検索すればいい話
187(1): デフォルトの名無しさん [sage] 2022/06/30(木) 16:46:00.43 ID:4XQ6AH+7(1/2) AAS
バラバラな日付が入っているテーブルから、
特定日以前3日間のレコードを取るSQL教えてください
hogeテーブル
id,date
5,2022-06-30
4,2022-06-19
3,2021-12-24
2,2021-06-03
1,2021-01-02
ここから2022-06-19以前の3日間のレコード
2022-06-19
2021-12-24
2021-06-03
を取りたいです
278: デフォルトの名無しさん [sage] 2024/10/14(月) 14:18:28.43 ID:/mng7eSx(1) AAS
日本語が読めないのかSQLを全く知らないのかわからんが救いようのないバカなのは間違いない
285(1): sage [] 2024/10/28(月) 17:18:52.43 ID:ehQdeP61(2/2) AAS
これが条件後出しカッコ悪いというやつか
325(1): 警備員[Lv.4][新芽] [sage] 2024/11/12(火) 16:45:36.43 ID:+Q7wUFQ5(2/4) AAS
WHEREによるフィルタが先で、SELECTによるマップがあとなのかな
370: デフォルトの名無しさん [sage] 2025/01/06(月) 20:05:07.43 ID:PWtKQBnB(1) AAS
>>369369(1): デフォルトの名無しさん [sage] 2025/01/06(月) 18:37:10.53 ID:xyyiC8Hr(1) AAS
>>366
ありがとう
やってみる
逆にそれでサブクエリの感覚が掴めるかもしれないと勝手な期待をしている
accessとExcelVBAでやっているけど、IT素人のPC好きなおじさんがやる
やってるから何分感覚がつかめない
ミックさんのデータベース入門は読んでいるけど読み切れていない
そうそう、その視点や観点が本当に大事
プログラム全般そうだけど一気に書こうとするとスパゲティ化して自分でも訳わからなくなるから
必ず最小から始めて、それらをくっ付けて大きくしていくみたいな感覚が大事
399(1): 警備員[Lv.3][新芽] [sage] 2025/01/22(水) 01:45:12.43 ID:x9n06qn/(1/2) AAS
>>390390(1): デフォルトの名無しさん [sage] 2025/01/21(火) 11:15:04.33 ID:+xYYoS0+(1/2) AAS
>>389
DBの構成上、主キーであれば最低限１つのインデックスは張られる
それはPK1,PK2,PK3全部揃ったときにB木を辿れればいいだけなので、6(=3P3)通りのどれかだが、
何もなければ PK1->PK2->PK3 の1つのインデックスになる
この場合、PK1,PK2 のセットならインデックスが使えるが、今回のように PK2, Pk3 のセットだと使えない
これはクエリプランを見れば判断出来る
SQLiteだとこのケースでは上記の通り
というかCREATE INDEX時(CREATE TABLE時)に使われ方を予測する事は不可能なので、
DBとしては、記述通りPK1->PK2->PK3で一つ作るか、全組み合わせを作っておくかしか出来ない
よく使われる検索に対して自動的にインデックスを作成して高速化してくれるDBがあるのかもしれんが俺は知らん
>>397397(1): デフォルトの名無しさん [sage] 2025/01/22(水) 00:08:11.72 ID:l3OLrM1a(1) AAS
{PK1,PK2,PK3}で複合キーが定義されてる場合
検索条件が{PK1}か{PK1, PK2}か{PK1, PK2, PK3}であればどのDBMSでも大半のケースでインデックスが使われる
検索条件が{PK1, PK3}の場合はPK1のselectivity次第でインデックスが使われるものがある
検索条件が{PK2, PK3}のように一番左のカラムが含まれない場合はindex skip scanという機能が実装されてなければインデックスは使われない(Accessにはたぶん実装されてない)
他のクエリとの兼ね合いで複合主キーを構成するカラムの順序を変更できないということであれば該当クエリ用に複合インデックスを追加するのは妥当
ありがとうございます
最左のカラムを検索キーとするかがポイントなんですね
当初は>>390での指摘がピンときていませんでした
合間のレスで「仮に(PK1,PK3)で検索し」は迂闊でした
いまは手元に試験用のコードがありませんが、最左のカラムを含んでいなかったと思います
SQLをずいぶん自由に書けるようになったと思っていましたが、テーブル、インデックスの作成がこんなに大切だったと知りました…
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.022s