タグ

関連タグで絞り込む (63)

タグの絞り込みを解除

設計に関するmikage014のブックマーク (470)

  • プライマリキーにUUID v7/ULIDを使うか問題について


    MySQLでUUID(v4)をプライマリキーにしてはいけない理由データベースの設計でプライマリキーをどうするかは、最初に悩むところではないかと思います。特にコンシューマー向けのWebサービスやマルチテナントのB2Bサービスを開発するときなどは特に気をつかいますよね。 何も考えずにAuto increment︵自動採番︶型のプライマリキーを付けて、﹁/users/1﹂﹁/users/2﹂﹁/users/3﹂みたいなID付きのURLでアクセスさせてしまうと、次のような問題が生じることがあります。 URLに使われているIDの大きさや増加数から、システムの規模感や利用状況が分かってしまう。IDを機械的に変えて総当たり的に情報を取得できてしまう。また、分散したシステムでサブシステムごとに衝突しないIDを割り当てたいことがあるかもしれません。そんなときにUUIDをプライマリキーにしちゃえばいいんじゃね

  • [提案]テーブル名はもう全部単数形にしようや


    こんにちは、データベース愛好家のみなさん！今日は、データベース設計で永遠の議論となっている﹁テーブル名、単数形vs複数形問題﹂について、徹底的に掘り下げていきます。私は単数形派です！でも、なぜそうなのか、一緒に深掘りしていきましょう。 イントロダクション‥我らが主人公、単数形くん みなさん、こんな経験ありませんか？ You: テーブル名って、users? user? どっちがいいんだろう... 先輩: いや、絶対usersだよ！Rails使ってるし。 You: でも、user_idって書くときは単数形だよね？ 先輩: あ、そうだね...でもやっぱりテーブルは複数形！ You: ︵心の中で︶なんかモヤモヤする... 実は、この﹁モヤモヤ﹂には理由があるんです。今日はその理由を解き明かし、単数形テーブル名の魅力をお伝えします。準備はいいですか？Let's dive in! 言語の壁を突破せ
    [提案]テーブル名はもう全部単数形にしようや

  • 大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG


    こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では﹁開発ガイドライン﹂と﹁バッチ開発ガイドライン﹂を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
    大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG

  • 熟練が必要なUIについて、それがよくない理由と、UIの慣性について


    久しぶりに記事を書く。最近マルス端末のUIについてツイートがあった。 この件に関して、UIについてやUXに対して日々やってきている人間は﹁ダメなUI﹂という認識の人が多いように思う。一方で、システムの開発者にとってはこれは、その認識でない人間が多いようだ。なので、この辺を私なりに意見を書いておこうと思う。 まぁ、これはいつもなのだが、書いていることが散らかってる。基本的に音声入力のメモなので、読みにくいかもしれないが読んでくれ参考になれば幸いだ。 熟練が必要なUIは基本的によくない まず、基本的に熟練が必要なUIはそもそも良くないって話をしていく。順番に話していこう、まず、熟練が必要なUIが支持される理由を考え、それに対して、批判していき、なぜ熟練が必要なUIはダメかを語ってみよう。 熟練が必要なUIが支持される理由 その前に、こういった熟練のUIが支持される理由についてかいておこう。それ
    熟練が必要なUIについて、それがよくない理由と、UIの慣性について

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

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

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

  • 【ソフトウェア設計】例外処理を考える

    はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？　予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。

    【ソフトウェア設計】例外処理を考える

  • データベースの在庫の持ち方をビットで管理してる話 - 一休.com Developers Blog


    こんにちは、一休.comスパ(以下、﹁スパ﹂)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う﹁在庫﹂は、﹁ある日付の特定の時間に対する空き枠﹂です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく﹁在庫﹂をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください！ https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
    データベースの在庫の持ち方をビットで管理してる話 - 一休.com Developers Blog

  • マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy

    # 実装の参考資料 - https://soudai.hatenablog.com/entry/2022/11/11/110825 # 類似の登壇内容の動画 - https://www.youtube.com/watch?v=PXy6I-AeI-I

    マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy

  • 履歴データテーブルとの向き合い方_PHPerKaigi2024

    PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222

    履歴データテーブルとの向き合い方_PHPerKaigi2024

  • SaaS アーキテクチャ概要

    SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。

    SaaS アーキテクチャ概要

  • RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag

    PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134

    RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag

  • 非同期ジョブをユーザーアクションに組み込まない


    (勤務先に投稿した社内ブログの焼き直しです) ある日同僚から ActiveJob の perform_later で Barbeque にキューした非同期ジョブの起動が遅いと言われた。が、非同期ジョブの使い所について個人的な考えを書いてみることにする。 相談は﹁非同期ジョブの結果をユーザーに返しているため、高速になって欲しい。現状、最大で数分の時間を要す旨のメッセージを表示している﹂という内容でした。具体的には {内部 API} が重く、一部の処理を非同期ジョブにしていてユーザー体験の悪化につながっているとのこと。 盲目的に非同期にしても嬉しいことはない 結論としては、非同期にするのであれば丁寧にやれば良いけど、そもそも同期的でよくない?と考えて欲しいと返した。 まず、個人的にはユーザーアクション起因かつユーザーへフィードバックする必要のある処理を非同期ジョブにするのは本当に長時間かかる

  • AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

    これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr

    AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

  • 実践Immutable Data Model - 紙箱


    ランキング参加中プログラミング はじめに この記事では、Immutable Data Modelと呼ばれる設計手法をもとに、リレーショナル・データベースにおける、テーブル設計の話を書いています。また、今回の実践で利用する、別の考え方の背景を理解するために、Out of the tar pitという小論文の内容にも言及します。 ﹁状態とは何か？﹂というややこしい話がたくさん出てきますし、データベースのテーブル設計についての話であることから、たくさんのSQLが出てきます。なので、データモデリングとか状態管理とか、特にSQLとかに興味がない人には面白くないと思います。 そのあたりに興味ある方は、読んでみて欲しいです。 Immutable Data Modelを、実際のアプリケーションで使うデータベースに採用するにあたり、どういう考え方で、どのようにテーブルを構成したか、自分なりの経験を書いていま
    実践Immutable Data Model - 紙箱

  • Laravelでの開発を例に考える、SimpleとEasyの違い - Part2


    2019年2月16日、PHPのフレームワークであるLaravelをメインテーマに据えた技術カンファレンス﹁Laravel JP Conference2019﹂が開催されました。﹁LaravelJP﹂を冠したイベントとして日本初開催となる今回。数多くのLaravelユーザーが参加し、知見を共有します。プレゼンテーション﹁SimpleとEasyは違う﹂に登壇したのは、株式会社クラシコム廣瀬健氏。講演資料はこちら 不要なものは消す まず、そもそもの大前提からです。不要なものは消そうって話です。 アプリケーションに1個、複雑な部分がある。その複雑さがそのままのうちは、まだなんとかなるかもしれない。でも、例えば機能の拡張、あるいはそれのスケーリング、あとは開発環境を用意しましょうというときに、その複雑さをさらになんとかしようと思うと、もっともっと複雑になっていく。 その複雑さの理由にはいろいろある
    Laravelでの開発を例に考える、SimpleとEasyの違い - Part2

  • Laravelでの開発を例に考える、SimpleとEasyの違い - Part1


    2019年2月16日、PHPのフレームワークであるLaravelをメインテーマに据えた技術カンファレンス﹁Laravel JP Conference2019﹂が開催されました。﹁LaravelJP﹂を冠したイベントとして日本初開催となる今回。数多くのLaravelユーザーが参加し、知見を共有します。プレゼンテーション﹁SimpleとEasyは違う﹂に登壇したのは、株式会社クラシコム廣瀬健氏。講演資料はこちら SimpleとEasyは違う 廣瀬健氏︵以下、廣瀬︶‥株式会社クラシコムの廣瀬と申します。よろしくお願いします。 ︵会場拍手︶ ありがとうございます。入社が一昨年の12月なので、ちょうど1年経ったくらいですね。前職まではRailsをやってて、クラシコムに入ってからLaravelを触るようになりました。 会社のエンジニアのブログでRailsとLaravelの比較記事を書いたり、あとさっ
    Laravelでの開発を例に考える、SimpleとEasyの違い - Part1

  • キャッシュを活用するために必要な知識と勘所 - そーだいなるらくがき帳

    どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ

    キャッシュを活用するために必要な知識と勘所 - そーだいなるらくがき帳

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


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

  • 開発者が知るべきキャッシュ設計でよく遭遇する問題


    はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない
    開発者が知るべきキャッシュ設計でよく遭遇する問題

  • コードや設計で「シンプル」が良いのはわかるが実際にどうすれば良いだろう？｜牛尾　剛


    先日、IaC (Infrastructure as Code) のコードを書いている時に自分が体験したシンプルさの威力の体験と、どうやったら﹁シンプル﹂に設計・コーディングができるか？ということについて調べてみたので整理したい。 ﹁はじめて﹂の人に敗北　先日、私がSLA Siteというアプリのデプロイスクリプトを terraform で書いていた時のこと。このSiteは内部で機能に何か問題が起きた時にお客さんより先に気づくための仕組みで、私は、Azure Functions のVNet インテグレーション、Managed Indentity、KeyVault Reference といった機能が正常に動作さするか確認するためのアプリを作っていた。 Azure Functions は対応する Event Source の数が多いため、私は、沢山のサイトを作り、Vnet インテグレーショ
    コードや設計で「シンプル」が良いのはわかるが実際にどうすれば良いだろう？｜牛尾　剛
  • 1 2 3 4 5 6 7 8 9 10 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.