  |
はてなキーワード: ODBCとは
たとえば ↓
https://www.launchexcel.com/what-jobs-use-excel/
https://www.fdmgroup.com/news-insights/advanced-excel-skills
ジャップランドで起こりがちなことはアメリカでは無いのかAIちゃんに尋ねてみたらこう言ってたよ
ワイ： 質問: 2024年において、アメリカの大企業および中小企業の間で、より一般的なデータ管理の方法はなんですか？ 検索して最新のトレンドを教えてください。 - 方法A:内部データベースからCSVファイルとしてデータをダウンロードし、Excelで修正してから、
ETLツール（例：Informatica PowerCenter、Talend Open Studio）、BIツール（例：Tableau Prep、Microsoft Power Query）、
または他のデータベース（例：OracleDB）などの他のシステムにインポートする。 - 方法B:Excelのステップをスキップし、内部データベースを他のシステムに直接接続する。 - 方法C:レガシーシステムや複雑なシステムには方法Aを使用し、その他のシステムには方法Bを使用する。状況やシステム要件に応じて使い分ける。 質問のポイント: - 大企業におけるExcelの使用:大企業はデータクリーニングのためにExcelを使用するのを完全にやめましたか？それとも、古いメインフレームシステム、ERPシステム、または特定の業務プロセスの問題のためにまだ使用されていますか？ - 方法A、B、Cのシナリオ:各方法の具体的なシナリオと製品名を教えてください。 - 2024年におけるCSVファイルのダウンロード:2024年現在、ETL/BIツールやクラウドベースのDWHを利用できないどころか、Oracle Gatewayなどの接続手段も利用できないデータベースの使用は完全になくなりましたか？
もしそのようなデータベースが2024年にもまだ存在する場合、直接的なデータ連携が困難なため、CSVファイルでのデータ抽出が唯一の方法となることがあります。
企業は膨大なコストがかかるために移行を延期していますか？それともすでに段階的に対応していますか？ - Excelを使い続ける理由: 内部データベースを他のシステムに直接接続した方がシンプルなのに、なぜ一部の企業はデータクリーニングのためにExcelを使い続けているのですか？
↓
2024年には、大企業の間でメソッドB（直接接続）へのシフトが顕著になっています。しかし、特定のシナリオに応じてメソッドC（ハイブリッドアプローチ）も採用されています。中小企業においても、直接接続の利便性と効率性が認識され、その採用が徐々に増加しています。しかし、リソースとコストの制約により、Excelを使用したデータクリーニングやハイブリッドアプローチが依然として一般的です。
使用状況: この方法は、中小企業、レガシーシステム、複雑なデータ構造を含むシナリオで依然として一般的です。Excelはその柔軟性と使いやすさから、データ操作のための多用途ツールとして広く使用されています。
シナリオ:
製品:
具体的なシナリオ:
使用状況: この方法は、大企業や技術に精通した中小企業の間でますます一般的になっています。直接接続を利用することで、データワークフローが効率化され、手動エラーが減少します。
シナリオ:
製品:
具体的なシナリオ:
使用状況: 多くの企業が、レガシーシステムや複雑なシステムにはメソッドAを、その他のシステムにはメソッドBを使用するハイブリッドアプローチを採用しています。この柔軟性により、既存の制約と近代化の努力をバランスさせることができます。
シナリオ:
製品:
具体的なシナリオ:
データ管理ツールの進歩にもかかわらず、Excelは大企業におけるデータクリーニングと操作のために広く使用されています。これは主に以下の理由によります：
ETL/BIツールやクラウドベースのDWHと直接統合できないシステムに対して、データをCSVファイルとしてダウンロードすることは依然として一般的です。企業は高コストと複雑さのために移行を遅らせることが多く、段階的に対処しています。
しかし、直接接続はより効率的で広く採用されており、長期的にはデータ管理におけるExcelへの依存が減少すると予想されます。
クラウドベースのデータ統合ソリューションの台頭により、データ収集、クリーニング、統合がAI/ML技術によって自動化され、手動作業が減少し、データの一貫性と精度が向上しています。AI/MLアルゴリズムは、異常検出、欠損値の補完、パターン認識などのタスクを効率的に処理し、データ品質を向上させます。リアルタイムデータ分析の利点が明らかになるにつれ、直接接続の採用が増加し、より迅速かつ正確なビジネス意思決定が可能になります。
データセキュリティ、コンプライアンス、およびデータガバナンスの重要性が増すにつれ、このトレンドは続くと予想されます。
できたできた。自己解決。多分誰にも役に立たないだろうが書いておこう。
DB2はODBCの設定以外にNodeとDBの設定情報が必要らしい。それがなんなのかはわからない。
GUIのODBCデータソースで追加すると、これが裏で作ってくれるっぽいが
ODBCCONF.exeでは作ってくれず、エラーとなる。らしい。
"C:\Program Files\IBM\SQLLIB\BIN\db2cmd.exe" /c /w db2 catalog tcpip node FOO remote 192.168.1.1 server 10000 "C:\Program Files\IBM\SQLLIB\BIN\db2cmd.exe" /c /w db2 catalog db FOO at node FOO odbcconf /A {CONFIGSYSDSN "IBM DB2 ODBC DRIVER - DB2COPY1" "DSN=FOO|DATABASE=FOO|SYSTEM=192.168.1.1:10000|UID=db2admin|PWD=password"}
で追加できる。知らんだけで最後はODBCCONFではなく、db2側のでDSNも追加できるのかもしれない…
さらに「 - DB2COPY1」が何なのかさっぱりわからん。「IBM DB2 ODBC DRIVER」もあるんだけども。
というか、こういう要望無いんだろうか？探してもAIに聞いてもなかなかヒットせず
リファレンス見ながらだましだましやってやっとたどり着いた。
odbcconf /A {CONFIGSYSDSN "IBM DB2 ODBC DRIVER - DB2COPY1" "DSN=FOO|DATABASE=FOO|SYSTEM=192.168.1.1:10000|UID=db2admin|PWD=password"}
だと「ドライバーの ConfigDSN、ConfigDriver、または ConfigTranslator が失敗しました」とあてにならないエラーが出てしまう。
iAccessは
odbcconf /A {CONFIGSYSDSN "iSeries Access ODBC Driver" "DSN=BARLIB|DRIVER=IBM i Access ODBC Driver|SYSTEM=192.168.1.1|DefaultLibraries=BARLIB|CMT=3|SORTTYPE=2|LANGUAGEID=JPN"}
なんかちがうんかなぁ。。。
というかトランザクションを見逃してた、トランザクション上手くやりたいならまともなDBMS入れないと無理
誰も使ってないWindows PCとか転がっていればSQLServer Express（無料）とか入れてやる？通信の面倒くささでいえばSQLiteと一緒だろうけどエンドユーザー側がドライバとかインストールする必要はないはず（ODBCデータソースの設定は必要、めんどくさい……）
どうせODBC使うならドライバインストールくらいって思ってついでに増田がLinux慣れしてるなら鯖立ててポスグレでもMySQLでも何でも使えばいいと思うけど
SQLServerのOLEDB接続、廃止されたもんだと思ってたら復活していたらしい エンドユーザー側の設定不要だと思うからこれが一番楽かも？
追記2
有益な話だし、GPL関係でググってこのページを見た人のために勝手に補足と個人的な疑問を放流してみる。
適当に調べてた知識を記憶をたよりに書いているので、間違いがあれば容赦なく指摘して欲しい。
# どうでもいいけど、元増田の話でOSがLinuxだったりしたら笑うw
GPLは元増田で書かれている通りで、WEBシステムを閲覧しただけではソースコードを請求することはできない。RMSらもこれには気づいていて、この穴を塞ぐためにAGPLというライセンスができた。このライセンスのソフトウェアを利用した場合、WEBシステムであろうと利用できる人はソースコードの請求を行えるようになる。
これは別にWEBシステムに限らず、ユーザーが何らかの形で利用できるシステムなら、ソースコードの請求が行える。
申し訳ないが詳しい所は知識不足でよくわからない。だけど、下記の記事の通り現在の開発元のOracleの見解である。すなわち、MyODBC(GPLのMySQL用ODBCドライバ)を使わず、GPLでないドライバを用いて接続してしまえば、開発したソフトウェアがGPLにならない。
http://plaza.rakuten.co.jp/matsunopage/diary/201011300000/
# 個人的にGPLがRMSの著作権Hackなら、OracleのコレはGPL Crackだと思っている。「GPL汚染が嫌なら有償ライセンスで契約しろ」と言われた話を聞いた事があるからだ。
おそらく持ち帰れないのではないかと思う。なぜそう思うかというと、普通、プログラマが書いたコードの著作権は会社に取られるし、GPLでライセンスされたソフトウェアを受け取ったのは会社であってプログラマ個人ではない。GPLでライセンスされたソフトウェアを物理的にもっていく事は可能でも、きちんとライセンスを受けた訳ではないので機密情報の漏洩にしかならないと思う。
単純な興味なのだけど、例えば最初はGPLだったが途中からはプロプライエタリ(ないし、GPL非互換なライセンス)に変更可能なのか知りたい。個人的な考えでは、著作権者全員の合意がとれれば可能という結論。著作物をGPLに書かれた通りに扱ってよいとしただけで、著作権者によって著作物の扱い方は変更可能だという考えから。無論、GPLでライセンスされたプログラムを受け取った人はソースコードの請求は依然として可能。
http://nippondanji.blogspot.jp/2010/06/gpl.html
http://d.hatena.ne.jp/karasuyamatengu/20110126/1296004598
なんで、グレーなのか。なんで、無理なのか。どのような考えでグレー、無理という結論を出しているのかきちんと書いてもらえますか？ 私の考えが間違っているならなぜ間違っているか指摘していただけますか？ あるいは、下記の増田さんのように具体事例を出してもらえますか？ プロプライエタリに戻せないというのなら下記の具体事例はどのようにお考えですか？
http://anond.hatelabo.jp/20140722071548
とした場合に、PHPを飛び越えて(間接的にしか接続していないにも関わらず)開発したシステムにGPLが適用されるということですか？ その場合、PHPにもGPL汚染が発生するということになると思いますが、間違いありませんか？(FOSS除外規定を設けているのはMySQLであって、FOSS除外規定と無関係な開発したシステムがGPLになってしまうと、開発したシステム側からGPL汚染が発生するという考えから。)
元のパラグラフは下記の通りです。
あと、MySQLのデータベースサーバに接続しただけではGPL汚染は発生しません(AGPLはそのためのものなのは前述の通り)。また、PHPは接続するクライアントになりますよね。ということは、MySQLと一緒に開発システムを一つのパッケージとして納品しない限りはGPL汚染は発生しないのではないでしょうか？(WEBシステムでそんなこと普通しませんよね。yumとかでインストールするし)
根本的な問題として、FOSS除外規定はGPLソフトウェアと他のFLOSSをリンクする際の問題を解決する物であって、MySQLのデータベースサーバに接続する場合には関係のない話だと思います。おそらく、問題だとお考えなのは、PHPのドライバがOracle製のGPLプログラムをリンクしていたためPHPのドライバを利用すればそのような問題が発生するという事だと思います(さらに追記。この通り書かれていますね。よく読んでおらず、失礼いたしました)。現状、PHPライセンスとなっているMySQL Native Driverを利用すればそのような問題は発生しないはずです。
http://php.net/manual/ja/mysqlnd.overview.php
かりに、おっしゃる通り、開発システムもFOSS除外規定に含まれるFLOSSにしなければGPLになってしまうとした場合、それはMySQL独自の問題であり、他のFLOSSに一律で当てはまる問題ではないということでよいでしょうか？ なぜこのような質問をするかというとMongoDBが同じような問題を抱えているからです。下記のURLの通り、MongoDBのコアサーバはAGPLですが、ドライバにApache licenseを適用し、開発システムにAGPL感染が発生しないようにしています。
http://www.mongodb.jp/mongo/licence
上記の様なケースにも実用的に対応する為、（AGPLを採用しつつも）我々はあなた方の（MongoDBを利用する）クライアントアプリケーションは（MongoDBとは）別物扱いする事を約束します。これを円滑に行う為、mongodb.orgサポートのドライバー（あなたのアプリケーションとリンクする部分）はApache licnese（コピーレフト）の元公開します。
返信お待ちしております。
冒頭に書いた通り、間違いがあれば容赦なく指摘してください。
