SQLなら俺に訊け [無断転載禁止]©2ch.net (457ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
16: デフォルトの名無しさん [sage] 2017/11/03(金) 23:58:59.47 ID:N8t7Jq3a(5/5) AAS
あ、いや、違いましたね。
read_uncomitted は制限を緩和する方向でした。
まだ全貌を把握しておらず、ここら辺はすみません。

SQLiteはseriarizableを実装しているとは書いてありますが、デフォが何かはよく分かりません。
> SQLite implements serializable transactions
> 外部ﾘﾝｸ[html]:www.sqlite.org

ただまあ、今のところ複数selectをトランザクションに指定する方法が分かりません。
多分単発のselectなら自動的にトランザクション化してます。
209: デフォルトの名無しさん [sage] 2022/07/03(日) 23:34:25.47 ID:fr0a/itN(1) AAS
ソートの話は相関サブクエリを使えという話じゃなく
指定日以前の任意の3レコードなのか(ソート無し)
指定日以前の直近の3レコードなのか(ソート有り)
という違いを指摘したかったんでしょ
262(1): デフォルトの名無しさん [sage] 2024/04/15(月) 16:47:19.47 ID:fSSptXgn(4/5) AAS
むう？なんか書き込み失敗して内容も失ったが、覚えてる範囲でもう一度書く。
復活して同様の物が連投されてたらご容赦を。

>>259-260
LINQはSQL風にC#を書ける物で、C#のArrayに対してSQLを発行できるものではなかったと思ったが違ったか？
俺は後者だと思ってたが前者だったので絶望した。あれが有用になる局面がよく分からん。

俺が希望してたLINQ：
.NETのStreamクラスが匿名パイプ/ネットワークストリーム/ファイルの抽象クラスのように、
.NETのArrayや各種DBに対してSQLを発行できるもの
(つまり、接続先がDBなら通常通り、接続先をArrayにすればオンメモリDBとして、同一コードで一文字も変更なく動く物）

実際のLINQ：
for文を書きたくないでござる、だけのクソったれ

俺はあくまでSQLでDB管理する前提で、LINQが何らかのラッパを提供するものだと思ってた。
だから実際のLINQ見て使えねえと判断したが、全く違う方法でDB管理するのかあれは？
俺は勝手に、SQL書けるがC#書けない奴をC#側の戦力として取り込む文法かと思ってたが。

が、まあ、
> プログラミング言語同梱のリレーショナルデータベースAPI
がLINQ等を指すのはわかった。そして ID:YG3lrvG/ の書き込みを読み直すと、
もしかして自前でSQLインタフェース提供しようとしてる？
ならそれは諦めて、DBをPostgreSQL等に移行するほうが妥当だと思うぜ。
414: デフォルトの名無しさん [sage] 2025/01/22(水) 18:46:15.47 ID:VcBzYOin(7/7) AAS
>>413
413(1): 警備員[Lv.8][新芽] [sage] 2025/01/22(水) 13:46:46.67 ID:ZVwqoD6m(3/3) AAS
>>405です

途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
また、複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました

理解不足は否めませんが、実用上問題がないレベルとなったので、これでよしとします
ありがとうございました
> 複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
当たり前、というかDBの使い方の初段階で説明/理解すべき事柄

> 途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
> と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
そうじゃない
ひととおり設計を理解した上で弄くり回して理解を深めるのなら身に付くが、
今の君のように、何も理解してない状態で試行錯誤したところで時間の無駄でしかないよ
(それよりは記事を漁って理解するまで何度も読み込む努力をした方が何倍もいい)

とはいえ、現実問題としてaccessの実アプリの方が優先なのは分かる
半年に一度くらいしかSQLも書かないのなら今の状態もありだ
ただ、毎日SQLを書いてる状況なら、どのみちいつか理解しなければ不便で仕方ないだけなので、
出来るだけ早いうちに理解を深めておくべき

例えばさ、>>383
383(3): 警備員[Lv.1][新芽] [sage] 2025/01/20(月) 18:23:14.14 ID:O4abJDGp(1/3) AAS
次の3つのフィールドで構成される複合主キーがあり
(PK1, PK2, PK3)
検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
に戻ると、(この事を言ってるのかもしれんが)
複合主キーを(PK1, PK2, PK3)ではなく、
(PK2, PK3, PK1)としてテーブルを作成しておけば、今回のインデックスを別に作成する必要はなかったろ
だからテーブル作成時の時点で、将来どういうクエリが発行され、インデックスがどう適用されるかも設計されてるし、
逆に今の君のような状態では、適切なテーブル設計は出来ないんだよ
というか、
> 検索キーとしてPK2とPK3だけをよく用いるとき
の場合はむしろ(PK2, PK3, PK1)とするのが普通で、
つまり今回はテーブル設計を間違えてて、それは君がインデックスが何たるかを理解してないから
勿論追加でインデックス張ればクエリは高速にはなるけども、修正の仕方が正しいわけではないよ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s