「SQL」の読み方論争に決着？ 「しーくぇる」vs「えすきゅーえる」にPostgreSQLがケリ／冠詞にはくれぐれも注意【やじうまの杜】
UNIX データベース入門
稚内北星学園短期大学 経営情報学科 丸山不二夫 1994年 8月 5日 Contents 序章 リレーショナル・データベース概観 リレーショナル・データベースとは データベースは情報をどのように組織しているか 情報のいれものとしての「テーブル」 リレーショナルとは すべての関係は、テーブルである 関係演算 リレーショナル・データベース上の標準言語ＳＱＬ 本書でのSQLの扱い方の特徴 Select selectの基本形 テーブルから指定した項目を抜き出す select 見出しの変更の２つの方法 行内への文字列の表示 項目リスト中の式 from 句 テーブルの積 where句 検索条件の指定 論理演算 リスト null値 文字列の比較 likeとワイルドカード ジョイン テーブルの結合 項目名の修飾 三つのテーブルのジョイン テーブル名のエイリアス（別名） 自己自身とのジョイン サブ・クェリー
SQL50本ノックをSQLite3 Fiddleで試す - Gマイナー志向
Software Design「データベース速攻入門」に「SQL50本ノック」が掲載されました - LIVESENSE ENGINEER BLOG 最近では、postgres-wasmなど、WebブラウザでDBを動かせるようになってきており、もう少しすれば、WebAssemblyを使って、ブラウザですぐにノックを始められるようになるかもしれません。もしも、また何年か後に記事を更新する機会があれば、試してみたいですね。 Web上からすぐに試せるpostgres-wasmはPagilaのデータを持っていくことが現時点で出来なさそうだったものの、SQLite3 WebAssemblyはSQLiteのデータを持っていけました。SQL50本ノックを気軽に試せそうです。 手順1 sakila-sqlite3をダウンロード まずgithubからsakila-sqlite3をダウンロードします。 gith
MySQL JOIN Types Poster - Steve Stedman
So many times I have been asked for help with a query, where the question really comes down to the understanding of the difference between INNER and LEFT or RIGHT JOINs. I created this poster a few years ago and I keep it posted on the wall at the office. This way when I am trying to explain JOIN types, I just refer to the poster. I have created the poster below to help describe JOIN types in My S
ER図の自動生成について、dbdiagram.io, DBeaver, A5M2 を比較してみる。 - Qiita
はじめに データベース設計のER図について、自動で生成する以下３つのツールを比較した記事です。 dbdiagram.io DBeaver A5:SQL Mk-2（A5M2） 先日、こちらの記事をQiitaに投稿したところ、多くの方に記事を見ていただき、コメントも多数いただきました。 ER図に関するお勧めのツールをコメントいただく方が多くいらっしゃいました。 今回はその中から、無料でも利用できる3つのツールの「ER図の自動生成」の機能を試します。 比較の結論としては、〇〇が一番良いという感想ではなく、どのツールも多機能で、できることは違うので、今後使うときは用途や業務の環境によって使い分けていけたらと思っています。 目次 それぞれのツールについて、下記の内容を書いていきます。 1. dbdiagram.io 1-1. 始める 1-2. 使う 1-3. 感想 2. DBeaver 2-1. 始
Amazon RDS Proxy が BASE にもたらした期待以上の導入メリット - BASEプロダクトチームブログ
はじめに 基盤チームでバックエンドエンジニアをやっている松田（ @tadamatu ）です。 以前にCTO川口が当ブログ内で公開した以下の記事があります。 devblog.thebase.in 新規接続の限界 BASE のアクセス量の伸びは凄まじくこの構成でも接続エラーが発生するようになってしまいました。 ピーク時に秒間 2 万もの新規接続が primary インスタンスへ行われているといった状態です。 この記事が公開されたのが約２年前で、当時100万程度 だったショップ数は170万を超え、我々はまだまだ伸ばしたいと考えています。 これは、ショップ数の伸びとともに、指数関数的に増えていくユーザのアクセスを捌く必要があることを意味します。 ブログ公開当時、我々はさまざまな検討の末、以下のような対策を取りました。 残された手段は primary のインスタンスに対しての接続数を如何にして減らす
データベース設計におけるNULL - kawasima
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
あまり知られていないPostgreSQLの機能 | POSTD
あなたが知らない既存機能があるかもしれません！ マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre
DBMSの市場規模、DBaaSがオンプレミスに並ぶ。シェア1位はマイクロソフト、AWSがオラクルを抜いて2位に。ガートナーによる2021年の調査結果
DBMSの市場規模、DBaaSがオンプレミスに並ぶ。シェア1位はマイクロソフト、AWSがオラクルを抜いて2位に。ガートナーによる2021年の調査結果 調査会社のガートナーはデータベース管理システム（DBMS）市場における2021年の調査結果「DBMS Market Transformation 2021: The Big Picture」を明らかにしました。 DBMS市場は長らくオンプレミス向けのデータベース製品が市場の大半を占めていましたが、今回の調査によると2021年にはついにクラウド上でマネージドサービスとして提供されるデータベース、いわゆるDatabase as a Service（DBaaS、ガートナーはdbPaaSと表記）がDBMS市場の49％を占めることとなり、市場規模においてDBaaSとオンプレミスはほぼ横並びとなりました。 2021年のDBMS市場全体の規模は約800億ド
SQLの暗黙の型変換はワナがいっぱい
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月24日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、SQLにおいて「暗黙の型変換」を使うべきでない理由として、具体的な「ワナ」をいくつか紹介します。 数値項目に対するSQLインジェクション対策のまとめにて説明したように、RDBの数値型の列に対してSQLインジェクション対策をする方法として、以下の三種類が知られています。 バインド機構を用いる パラメータの数値としての妥当性確認を行う パラメータを文字列リテラルとしてエスケープする このうち、方法3を使うべきでない説明の補足です。具体的には、方法3には、「暗黙の型変換」が発生しますが、それが思わ
Consider SQLite
If you were creating a web app from scratch today, what database would you use? Probably the most frequent answer I see to this is Postgres, although there are a wide range of common answers: MySQL, MariaDB, Microsoft SQL Server, MongoDB, etc. Today I want you to consider: what if SQLite would do just fine? For those who are unfamiliar, SQLite is a implementation of SQL as a library — this means t
OracleからPostgreSQLに乗り換えたい人に送る何か - なからなLife
Calendar for PostgreSQL | Advent Calendar 2021 - Qiita の10日目の記事です。 思い当たる節がある人は、今の見積もりの数倍の時間と予算を確保してからキックオフして欲しい。 多分、そのまま走ると誰か倒れるから。。。 で終わりにするわけにはいかないので、いくつか書きます。 もちろん、SQLがDBMSによって「方言」があるので、使える構文、関数名が違うってのは当然あるのですが、それ以外のところを中心に。 PostgreSQLのサーバーサイドエンコーディングはShiftJISをサポートしていない 今どき、新規で立てるデータベースはUTF8を選ぶよねーキャハハ、と思っても、何世代もバージョンアップしてきたOracleや、塩漬けされたOracleなんかは、ShiftJISを使っているところも多いのではないでしょうか。 自分で文字コードマッピングの処
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話 - Qiita
起きた事 本番環境のデータ調査の依頼を受けた。その調査を受ける前に、それとは別で不要データを本番DBから削除する作業をMySQL Workbenchで行っていた。 本番DBで、データ調査を行う際にMySQL WorkbenchでSQLのselectと間違えてdeleteを実行してしまい、Tableを1つ丸ごとDeleteしてしまった。 ON DELETE CASCADEが親テーブルに設定されてしまっていたため、さらに4つのTable dataが芋づる式に消えてしまった。 ON DELETE CASCADEの説明としては、この記事がわかりやすかったです。 https://www.dbonline.jp/mysql/table/index11.html テーブルの構成(テーブル名などは例として挙げていて、実際のものとは多少異なります) 正しい設定 usersテーブルでuserを削除した時に、そ
Webフルスタックエンジニアになるためのチェックリスト
Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという
SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか？ 今回は、そんな方々にこそ
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLわかんねーーーーーーーー！！！！！！
文部省指導要項「情報」で高校生に教えることがネットワーク構築、開発手法、 DB、プログラミング、設計などと幅広く定められているが教えられる先生はいるのか
PGTune - calculate configuration for PostgreSQL based on the maximum performance for a given hardware configuration