Excel VBA 質問スレ Part83

**デフォルトの名無しさん** · 2025/06/08(日) 11:06:42.20

ExcelのVBAに関する質問スレ
コード書き込みや作成依頼もOK

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
Excel VBA 質問スレ Part82
https://mevius.5ch.net/test/read.cgi/tech/1737657075/1

**デフォルトの名無しさん** · 2025/10/01(水) 10:16:50.41

884が虚偽の記述をして、強弁とブラフで押し通し、いよいよ場が白熱したと見るや
ここが機会とばかり得意満面で6のワンペアを開いて見せたが、相手は3と5のツーペアだった　みたいなwww
法では無く当職通達によって事務方が正字一覧表を持っていて、正字に引き直された、というのが
事の真相であろう　先例主義の鎧を纏っている官吏は後から責任を問われる事態になるのをいちばん嫌うので
https://shihoshoshi.com/touki2030/archives/1841
https://4430.info/wp/wp-content/uploads/2017/12/誤字俗字・正字一覧表.pdf
https://www.bunka.go.jp/seisaku/bunkashingikai/kokugo/shoiinkai/iinkai_11/pdf/sanko_1.pdf
以上、884をコテンパンに出来た報告とす

**デフォルトの名無しさん** · 2025/10/01(水) 12:00:47.24

ある程度の数のレコード情報を保存するのに、Excelを使う場合とSQLiteみたいな簡易DBを使う場合とがあるけど、どこら辺で線引きするのが正解なんだろう。
取り回しは圧倒的にExcelの方が楽なんだけど、データの整合性みたいな点はDBの方が手堅いし。

**デフォルトの名無しさん** · 2025/10/01(水) 12:37:38.44

>>975
整合性で言えばExcelのテーブルは信用できるよ
MS的にもその辺を根拠にAccessのディスコン進めてた訳だし

**デフォルトの名無しさん** · 2025/10/01(水) 13:32:58.38

AテーブルとBテーブルを1:多で結合するようなケースって、ExcelだとAテーブル側のレコードを複数書き並べるようなイメージだったんだけど、そういう方法だとAテーブル側（1側）のレコード内の値が変更になった場合、整合性は必ずしも保証されなくない？（書き並べた同じレコード内の値を全て変更すれば大丈夫だけど、変更忘れがあると整合性が失われる）。
最近のExcelだと、そういったSQLっぽいこともできるようになっていたりする？

**デフォルトの名無しさん** · 2025/10/01(水) 13:41:54.46

最近というか2013のリレーションシップでは不足ということ？

**デフォルトの名無しさん** · 2025/10/01(水) 14:07:34.66

そもそもワークシートだとトランザクション使えないから、システムエラーのケースまで考慮すれば整合性の維持は極めて困難よ

**デフォルトの名無しさん** · 2025/10/01(水) 14:34:52.10

>>979
あー、なるほど。ロールバックとかできないということか。それだとたしかに厳密な意味でのデータの整合性に拘るのは難しいか……。

>>980
そういう機能もあるのね。あまり認識していなかったけど、ExcelだけでSQLっぽいことができるのはメリットだね。

**デフォルトの名無しさん** · 2025/10/01(水) 14:38:00.21

次スレも立てたよ。

Excel VBA 質問スレ Part84
https://mevius.5ch.net/test/read.cgi/tech/1759297002/

**デフォルトの名無しさん** · 2025/10/01(水) 14:52:13.45

SharePointに上げるとADODBでSQL使えなかった気が
リストだと5,000件の呪いがあるみたいだし

**デフォルトの名無しさん** · 2025/10/01(水) 15:03:30.89

>>980
なんかSQLを勘違いしてそうな気がする
SQLの代替って意味ではExcel2010からパワークエリーが使えるよ

**デフォルトの名無しさん** · 2025/10/01(水) 15:26:10.71

SQLはSQLiteでちょこちょこやっている程度なので、たしかにSQL自体について詳しいというわけではないが、SQLでいうところのJOIN 相当の機能じゃないの？

**デフォルトの名無しさん** · 2025/10/01(水) 15:35:12.95

整合性を云々言うなら問題はINSERTやUPDATEだね

**デフォルトの名無しさん** · 2025/10/01(水) 16:14:33.96

そういうデータの追加・更新時だよね

**デフォルトの名無しさん** · 2025/10/01(水) 17:23:31.74

参照だけでもパフォーマンス的にインデックス使いたくなったらDBでしょう
Excelはレコードが万単位になると遅くなってくるかな

**デフォルトの名無しさん** · 2025/10/01(水) 21:03:44.77

パワークエリーは2013から（しかも公式アドオン）です
パワークエリーはSQLの様な事をSQLより高機能にできます
ADOでSQLを一通り書いたから断言できる

**デフォルトの名無しさん** · 2025/10/01(水) 21:22:25.74

>>988
ADOでという書き方からして何もわかっていない素人丸わかり

**デフォルトの名無しさん** · 2025/10/01(水) 21:55:10.22

>>989
Power Queryだろうが、ADOだろうがJOINはJOINだし、GroupByはGroupByでしょう？
フィルターはフィルターだし、ソートは重い

**883** · 2025/10/01(水) 21:59:51.81

相変わらず質問スレでマウント取りたがるあたおかさん

**デフォルトの名無しさん** · 2025/10/01(水) 22:06:14.58

パワークエリってほとんど使ったことがないからSQLと比較してどうかってのは分からないけど、元データとして既存のファイルとかが使えるのは便利そうね。
テーブルとして保存しておくデータなら標準SQLでクエリを書いておく方が無難な気もするけど、手元のデータをぱっと処理するイメージならパワークエリみたいなものの方が手軽で便利な感じなのかな？

**デフォルトの名無しさん** · 2025/10/01(水) 22:14:16.84

>>992
Power Queryの方が圧倒的に手軽でしかも高機能ですよ。
SQLの要素の上にデータの前処理ができるETLがあるからです。
大量のデータでしかもサーバーにデータがあるとかならSQLの方が高速だと思いますが、個人で行う程度ならPower Query（と繰り返し処理を行う場合はBuffer関数）で十分です。
なぜならPower Queryは関数型プログラミングでもあるから。

**デフォルトの名無しさん** · 2025/10/01(水) 22:17:13.13

LET関数は便利だなと思った。
必ずエラーがある数式にLETで名前をつけて、If(IsError””,名前)にすればいい

**デフォルトの名無しさん** · 2025/10/01(水) 22:42:20.25

>>993
うわっ
個人でとか勝手に限定してきた

**デフォルトの名無しさん** · 2025/10/01(水) 23:02:36.67

データの前処理は、SQLというよりホスト言語でやることなのでは。Pytnonとかでやるより便利ならそこだけ欲しいかも。
関数型・宣言型っぽいというのはSQLからしてそう言われているよね（自分はミックさんの本で齧った程度の知識しかないけど）。

**デフォルトの名無しさん** · 2025/10/01(水) 23:12:11.99

SQLかT-SQLを導入してほしかったPowerQueryじゃなくて
規格化されて実績のある標準があるのになぜ車輪を再発明するのか

**デフォルトの名無しさん** · 2025/10/01(水) 23:26:25.36

Power Query-Power Pivotは好きよ

**デフォルトの名無しさん** · 2025/10/01(水) 23:37:46.31

なんでSQLとは違う物が実装されたかというと
そもそもPower Queryの前身はMicrosoft Queryという機能だったらしいです
個人ユーザー向けにGUIで手軽にデータの前処理や整形（ETL）が行える様にしたからSQLではない
ExcelにPythonが実装される前は、個人が勝手にPower QueryのためにPythonを Excelに導入していたくらいには高機能

**デフォルトの名無しさん** · 2025/10/01(水) 23:54:16.97

そもそもSQLをやろうと考えている様な人はデータは正規化して列の繰り返しのない、スカラ値の表を作るけど、大多数の人はめちゃくちゃ表の体をなしていないシートを作成するからSQLでは無理、不可能
列の値はバラバラだし
さらには列名を変えるし列は削除するし

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 115日 12時間 47分 36秒