JSON や CSV で SELECT * FROM したいときは columnq-cli が便利
techfeed 経由で下記のスレッドを見かけたのですが、タイトルだけでも既に面白そうです。 また、ちょっと前から Notion のデータベースを各種コンテンツへ変換するツールを作っていまして、これを組み合わせるといろいろ楽できそうな予感がします。 そのようなわけで、スレッドで紹介されていた columnq-cli についての記事です。 columnq-cli とは？ README を読むと「各種データをテーブルとして SELECT できるようにする CLI ツール」で、テーブルソースには JSON などの他に ROAPI でサポートされているものを扱えるとのこと。 (SELECT のみで更新はできない) ここで ROAPI とはなんぞやとなりますが、こちらは「ローカルのファイルシステムや各種サービスのデータを統合的に扱える(SELECT できる)サーバー」を構築できるそうです。 図 1-
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
SELECT文の結果を抽出条件に使う
この記事で分かること SELECT文を入れ子にするサブクエリー（副問い合わせ）の基本を解説 IN句を用いた条件指定から、サブクエリーを使った複雑なデータ抽出方法を紹介 ANYやSOMEといったIN句と類似する句との違いや使い分けについても説明
SQLアンチパターンを読みました
by @dekokun on 2013/02/26 8:15 Tagged as: SQL, 書籍. デプサミ2013で和田さんのSQLアンチパターンの講演を聞けなかった腹いせにSQLアンチパターンを購入して読んでおりましたが読み終わりましたので投稿。 だいたいの内容 世のシステムのかなりの割合で使用されているとおもわれるRDBMSを使用したシステムを作る際に開発者(DBAなど含む)が陥りがちなアンチパターンがまとまっている本です。 「インデックスショットガン(無闇やたらとインデックスを貼りまくる)」などの「そりゃ当然やっちゃいけないよね」と誰しもが納得するものから、「IDリクワイアド(すべてのテーブルにID列をつける)」など、一部の人には「あれ、それって何がダメなんだっけー」というもの、「リーダブルパスワード(パスワードの値を読める状態でDBに保存)」などの、いわゆる「DB設計についての
SQLアンチパターン
TOPICS Database 発行年月日 2013年01月26日 PRINT LENGTH 352 ISBN 978-4-87311-589-4 原書 SQL Antipatterns FORMAT 本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語
(初心者向け)SELECT文を考える時には最終アウトプットを強く意識する。
SELECT文を考える時、何となくjoinやgroup byとか使ってませんか？もしくはメインとなるテーブルを意識していますか？ SELECT文は非常に便利なので気づかないのですが裏で実行されている事は（非常に簡単に言うと） ・縦＊横の二次元の表を付きあわせ、新たな縦＊横の二次元の表を作成 しているだけなのです。 その際に、一行の粒度が変わる事に注意が必要です。多重度が大きい側にjoinすると、自ずと一行の粒度が変わってしまう（行が増えてしまう）為、初心者のうちは自分が何をしているのか分からなくなります。 例えば次のER図があり、 最終的に次のような表が欲しい場合、どういうSQLを書きますか？ 私は概ね次のステップでSELECT文を考えます。 ・最終アウトプットの一行の粒度を確認する。 この場合注文明細の行数が最終アウトプットの行数と同じ ・その粒度にあったテーブルをメインの表にする。 f
syboos.jp
We’re getting things ready Loading your experience… This won’t take long.
『SQL』
令和からの働き方について 元「傲慢SE日記」で、しばらく放置していました。 2020年からはこれからの働き方などについて書いて行こうかと思います。 先日SQLをプログラマーが書くのが良いのか、それともSQLを意識しない方が良いのかと言う話が議論になったのでそのことを纏めてみる。 今回の焦点を一言で言うならばO/Rマッパーは必要か必要ではないかと言う事に尽きる。今回の記事はSQLやオブジェクト指向、O/Rマッピング等を知っている方向けの記事なので、この辺りのことに興味がない方や知らない方は読み飛ばしてください。 プログラマーはSQLを知っている必要があるか否か？と言う議論だった場合は僕は即答で「DBを操作するプログラマーなら必要だ。」と答えるだろう。しかし、O/Rマッパーが必要かどうかとなると「オブジェクト指向プログラムをしているなら必要だ。」と僕は答える。 オブジェクト指向のネックのうち一
CREATE INDEX
SynopsisCREATE [ UNIQUE ] INDEX index_name ON table [ USING acc_name ] ( column [ ops_name ] [, ...] ) CREATE [ UNIQUE ] INDEX index_name ON table [ USING acc_name ] ( func_name( column [, ... ]) [ ops_name ] ) UNIQUE システムによって、(もし既にデータが存在しているのであれば)イン デックスが作成された時、及び、データが追加される度にテーブル内 の値に重複があるかどうか検査がなされます。 index_name 作成される、インデックス名。 table インデックスをつけるテーブル名。 acc_name インデックスで使用されるアクセスメソッド名。 デフォルトのアクセスメソッド
SQLの方言、複雑なSQLは遅い、スケールアウトについて：なにわのITベンチャー社長Blog - CNET Japan
コメント欄がちょっと炎上。 SQLにロジックを入れるにあたり、必ず問題になるのが表題の件。 ■ SQLの方言について 違いはあります。違いを大きいと感じるか、小さいと感じるかは人それぞれでしょう。同じだと思っていると戸惑うかもしれませんが、違いがあることを認知していれば、個人的には簡単に乗り越えられるレベルと感じています。 わたしが経験した順に。 ● Access RDBMSとはいえないけれど、パーソナルツールとして卓越していると思います。アドホックな仕事には最適ですね。 SELECT句、FROM句にサブクエリーが書けないと思っていました（たぶん、2.0ではできなかったと思うけれど……もしできてたら、苦労したから悔しい。手元にある一番古いAccess2000でも簡単にできてびっくりしました）。 ● Oracle ずいぶんやったな〜。 メジャーではあるけれど本当に癖が強い（と思う）。テーブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Access Tips #706 ユニオンクエリのUNIONとUNION ALLの違い | T'sWare
SQL講座 Accessで試してみよう
Rails3 Raw Sql Insert with Nested Models
リレーショナル・データベースの世界
GitHub - nkallen/arel: A Relational Algebra
『GitHub - nkallen/arel: A Relational Algebra』へのコメント