テーブル・DB設計するときの極意 - Qiita
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ ・テーブル・DB設計は「属性」と「関係」の２つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょう。 users / posts / comments / likes のテーブルが
Azure アプリケーションの設計原則 | Microsoft Docs
次の設計原則に従って、アプリケーションのスケーラビリティを上げて、回復力や管理しやすさを強化します。 自動修復機能を設計します 。 分散システムでは、障害が発生します。 障害の発生に備えてアプリケーションの自動修復機能を設計します。 すべての要素を冗長にします 。 単一障害点をなくすようにアプリケーションに冗長性を組み込みます。 調整を最小限に抑えます 。 アプリケーション サービス間の調整を最小限に抑えてスケーラビリティを実現します。 スケール アウトするように設計します 。需要に応じて新規インスタンスを追加または削除し、水平方向に拡張できるようにアプリケーションを設計します。 制限に対処するようにパーティション化します 。 パーティション分割を使用して、データベース、ネットワーク、コンピューティングの制限に対処します。 操作に合わせて設計します 。 運用チームが必要なツールを得られるよ
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
設計書には何を書くべきなのか - terurouメモ
設計とは、 要求（やりたいこと）をヒアリングする 要求を要件（何を満たさないといけないのか）に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する） 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案（いわゆる比較表で書いていくのが楽） 検証結果 選定・合意結果（合意した代替策や妥協ラインについても記載する） 詳細設計（どういう実装にするとか、パラメーターにするとか、細
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
