あまり知られていないPostgreSQLの機能 | POSTD
あなたが知らない既存機能があるかもしれません！ マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre
『継続して○○した日数』とその最大値をSQLで求める - REVISIO Tech Blog
こんにちわ。データ部の長野です。 TVISION INSIGHTSのデータ部では、複雑なデータ抽出をする機会が多々あります。 今回は最近おこなった複雑なデータ抽出ロジックの1つ、 「『継続して○○した日数』とその最大値」 をSQLで求める方法を紹介します！ ======= 2021/06/26追記 ======= 記事中に積み上げ和を表現するのに、SUM(not_cont_date_flg) OVER (PARTITION BY user_id) AS cum_not_cont_date_flgというコード記述があるのですが、以下のような御指摘を受けました。 先日の「連続で結果xが出た回数」の時もでてきたのだけど、もしかしてPostgreSQL/redshiftとBigQueryでwindow関数のsumの挙動が違う？BigQueryだと積み上げにならないでウィンドウごとの和（user_i
ドメインロジックとSQL - Martin Fowler's Bliki (ja)
以下の文章は、Martin Fowler による Domain Logic and SQLの日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジック
一行入魂 PostgreSQLでパフォーマンスに影響しない論理削除
論理削除を削除フラグや削除日時のカラムで実装すると、カーディナリティが低いので検索でのパフォーマンスが良くないです。 そこで、削除用のテーブルを作り移動することにします。 スキーマーを以下の三つにわけます。 source(全てのレコード) public(生きているレコードのみ) garbage(削除されているレコードのみ) sourceスキーマーにテーブルの定義を行い publicスキーマーとgarbageスキーマーにはテーブル継承したテーブルを置きます。 通常はpublicスキーマーを検索すればよいです。 もし、削除されているものも含めて欲しい場合、sourceスキーマーを検索できます。 スキーマーを作るSQL CREATE SCHEMA IF NOT EXISTS source; CREATE SCHEMA IF NOT EXISTS garbage; テーブルを作るSQL DROP
なぜ、正規化なのか。 - どんみや：楽天ブログ
2009.12.22 なぜ、正規化なのか。 カテゴリ：SQL-SERVER 正規化すべきか、しないべきか。 結論から正規化をすべき。 ただし、この正規化には注意が必要である。 正規化を行うことにより、下記のメリットとデメリットがある。 メリット ・データの冗長性（重複性）がなくなる。 ・なにより、業務的に１つ１つの項目の意図が明確になる。 ・全体的にみてデータ量が減る。 ・ER図（リレーション図）を確認するだけで、業務要素が理解できる。 ・テーブル構造だけで、ありえないデータの発生をブロックできる。 デメリット ・テーブルがバラバラになり、データ取得時にJOIN操作が増える。 ・そのため、速度が低下する。 ・コーディングが複雑になる。 ここで、重要だと感じるのが、あくまでも正規化は業務要素を リレーショナルデータベースで管理する上での、必要項目の 整理整頓である。 システム開発する中で、例
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - codemix/ts-sql: A SQL database implemented purely in TypeScript type annotations.
O/Rマッパーによるトラブルを未然に防ぐ