[B! database] klim0824のブックマーク

データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。

回答 (7件中の1件目) まずはUUID及びその対案として用いられる連番(自動採番)のメリット・デメリットを整理します。 (タイムスタンプキーや複合キーなどもその効率性から設計上有用なシーンはありますが、比較から除外します。) * UUIDを使うことのメリット * * データベースにSQLを送信する前からアプリケーションレイヤーでIDを生成できる。 * * トランザクション処理を実装しやすい場合がある。 * IDを推測しにくい。リソースが列挙可能ではない。 * UUIDを使うことのデメリット * * レコード・インデックスサイズが増加する。 * * ...

klim0824 2024/05/16

リンク

リレーショナル・データベースの世界

序文私の仕事は、DB エンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、人生は何があるか分からないものです)。そこで、です。このサイトの目的は、データベースの世界に足を踏み

klim0824 2024/03/01

database
SQL

リンク

ID生成方法についてあれこれ

ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのかまとめ ID生成方法以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える普通は64ビットの整数型を採用することが多い単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に

klim0824 2024/02/05

database

リンク

Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル） - Qiita

Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル）oracleWeb この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた！』でした。想定読者ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人イントロダクション皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか？帳票や大きな画像ファイルなどを扱う際、大きく分けて２つの設計方針があります。・DBに直接保存する・DB外部に保存し、パスなどをDBに保存するオライリーのSQLアンチパターンの、”ファントムファイル”という章にはこのあたりのことが書いています。 [Amaz

klim0824 2023/12/24

リンク

リーダブルSQL[より良いSQLを書くためのシンプルで実践的なテクニック] - Qiita

はじめに最近エンジニア界隈では「リーダブルコード」が話題なっていますね。リーダブルコードでは、このような定理が紹介されています。「コードは他の人が最短時間で理解できるように書かなければいけない。」 Dustin Boswell リーダブルコード P.3 より引用 SQLでも同じことが言えそうです。リーダブルなSQLを書いてないと結婚できない時代が今まさに到来しようとしています。皆さん、クソSQL1を読んだことがありますね？クソSQLを書いたことがありますね？僕は、あります。そこで、本記事ではどうしたらリーダブルなSQLが書けるかというアイデアを紹介します。処理の流れの順に上から読めるようにする人間のメンタルモデルは、問題やタスクを小さなステップに分割し、それぞれを順番に実行することに適しています。サブクエリを使ったSQLでは、処理の流れは上から下ではなく、ネストされた

klim0824 2023/09/16

SQL
database

リンク

ファイル書き込みをするプログラムで気をつけた方がよいこと | IIJ Engineers Blog

この記事についてこの記事では、ファイルに書き込みを行うプログラムを実装する時の注意点について説明します。ファイル書き込みは、プログラミングにおいて比較的よく利用される機能でありながら、実装時に注意していないと、システムクラッシュ（意図しない電源の喪失や OS のクラッシュ等）後にファイル上のデータが整合性を失う可能性、平たく言えば、データが破損する場合があります。今回の主な内容はトランザクションに関連する事柄で、ご存知の方からすると当たり前と思われることだと思われますが、執筆者がプログラミングの勉強を始めて以降知らない期間が長かったことと、他にもご存知ない方がある程度いらっしゃるのではないかと思ったため、このように記事にさせていただきました。また、ここで説明する注意点は、クラッシュ後にデータの整合性が重要でない場合は、気を付ける必要がないものであることを先に書いておきます。先にこ

klim0824 2022/07/07

リンク

Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス

読者対象ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とするまた，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め）導入一般的に採用されやすいプライマリキー用の値として，以下を考える。連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ

klim0824 2022/06/16

リンク

SQLが重いときに見るお気軽チューニング方法

SQLのチューニング方法昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話）また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加

klim0824 2021/05/08

リンク

Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応

Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり

klim0824 2021/02/03

SQL
database

リンク

あなたの知らない連絡先の世界

「iOSから連絡先をサーバーに同期させたい」用件を受け、iOSにはContact APIがあるから楽勝でしょ、と思ったあなた。しかしながら連絡先の構造はそんなに簡単なものではありません。ミドルネーム？Suffix？振り仮名？旧姓？そんなハマりやすい連絡先処理の説明やVCard変換など、サーバーのテーブル設計にも役立つiOSのContact APIについてお話しします。 (Androidの連絡先にも若干触れる可能性あり) iOSDC 2020

klim0824 2020/09/20

ios
database

リンク

MySQL Sample Database

We use the classicmodels database as a MySQL sample database to help you work with MySQL quickly and effectively. The classicmodels database is a retailer of scale models of classic cars. It contains typical business data, including information about customers, products, sales orders, sales order line it ems, and more. We’ll use this sample database in our MySQL tutorials to demonstrate a wide rang

klim0824 2020/04/30

SQLのサンプル

リンク

ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません用法用量を守り、個人の責任で業務に投入してください参考資料 2024/02/14追記実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか今北産業で頼むテーブルに状態を持たせず状態毎のテーブルを作る状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

klim0824 2018/05/02

database

リンク

論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ

互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。