タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
【入門】データベース設計まとめ - Qiita
はじめに 今回はデータベース設計について学び直したので内容をまとめていきます。 自分は2021年に新卒でWeb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではNext.js×TypeScriptを利用したフロントの開発をメインで行っています。 直近の開発案件でRailsを使ったサーバーサイドの開発を担当することになり、DB設計を触ったのですが体系的な理解をしていなかったので苦戦をしました。 実装はできたものの、データベース設計を「なんとなくの理解」で終わらせないように、体系的に学び直しました。 データベース設計の学習に関しては下記の書籍を参考に進めました。 スッキリわかるSQL入門 達人に学ぶDB設計 徹底指南書 対象者 データベース設計について基礎から学びたい人 何となくデータベースの設計をしている人 正規化について学びたい人 データベースとDBMS
（テーブルの構成は『SQLアンチパターン』p53を引用） このテーブルは要望とバグ報告が可能なチケット発行システムで利用されます。バグ報告の場合はseverity（重大さ）とversion_affected（影響のあるバージョン）の属性を含み、要望の場合はsponsor（要望元スポンサー）を含みます。そのほかの属性（date_reported, reporter, riority, status）は共通のものです。（以降、共通の属性を基底、issue_type別の属性をサブタイプなどと呼びます。） このような設計が取られる背景には、リレーショナルデータベースがそもそも拡張性に乏しく、その反面で開発者には少ない工数でシステムを拡張する柔軟性が求められるという点が挙げられます。ただ、RDB本来の責務である「データを守ること」に立ち返ったとき、この拡張性の乏しさは堅牢性の裏返しであり、基本的にメ
AIにマッチングアプリに必要なデータベース設計を考えさせてみたら、必要なテーブルを全部教えてくれました。【ChatGPT】
キナリ | FlutterFlow @kinari_kuramoto 試しに、AIにDB設計を考えさせてみたら有能すぎました。 これからは命令口調をやめて敬語を使おうと思いました。 #ChatGPT pic.twitter.com/C1cKQ3EufT 2022-12-01 16:58:36
データベース設計で絶対役に立つ命名規則
命名規則は大切とわかっていてもおろそかになりがちです。 現場の人と要件ヒアリングで忙しい時に、 「この項目名は大文字にすべきか小文字にすべきか？」 という結論がでない議論をしたくないですよね。 そんな時に役に立つルールを紹介します。 命名ルールは開発時や運用時の開発コストに想像以上にかかわってきます。 命名規則はプロジェクトごとに１から作成する必要はないので、このルールをデフォルトとして、細かいところは実情にあわせて使うことをおすすめします。
ER図とは?ER図とは、データベース設計工程におけるアウトプットとして代表的なものです。「ER」とは「Entity Relationship」の略であり、ER図を見るだけでシステムが扱うデータ構造やその関連性などがわかるようになっています。 本記事ではER図の基本的な書き方をわかりやすく解説した上で、要件からER図に落とし込む際のシミュレーションを行い、効率的にER図を描画できるツールを紹介します。もしあなたがデータベース設計を任された時は、ぜひ本記事を参考にしてください。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース設計の際に気をつけていること - 食べチョク開発者ブログ
検索が爆速になるデータベース設計を公開します
データベース設計におけるNULL - kawasima
スキーマを放棄したデータベース設計 - 『SQLアンチパターン』のEAVについて考察する
データベース設計・移行ツール「SI Object Browser ER」新版、動作環境を大幅に拡充
データベース設計には必須！ER図の書き方を解説！Excelでも書ける？
x.com
mount-lake.com
www.bunka.go.jp
kyoka.nm.bex.jp
typhoon.yahoo.co.jp
www.google.com