テーブル・DB設計するときの極意 - Qiita
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ テーブル・DB設計は「属性」と「関係」の２つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要
個人開発激安 GCP (にしたい)
とりあえず GCP で軽くサーバーとデータベース立ててみたいっつって脳死で使ってたら1日で 1800 円いって焦った。慌ててチャットサポートに聞いたらいろいろ教えてくれて安心したけど、もうちょっと調べてみためも。自分が使いそうなものしか書いてないよ。 Google Cloud Calculator めっちゃ便利。 App Engine TLDR これを app.yaml に書いておけば一番安上がり env Standard environment と Flexible environment があって、無料枠があるのは Standard だけ。他にも Flexible だと想定外の請求が来たりするらしい。なので Standard を指定しておく instance_class サーバのインスタンスの種類。F1 が一番しょぼいスペックのサーバで F1, F2 とかの "F" 系なら一日 28
【マジで】サイバー演習シナリオの作り方【怖い】 - freee Developers Hub
「CEOに身代金を要求したい」 こんにちは、PSIRTマネージャのただただし（tdtds）です。この記事はfreee Developers Advent Calendar 2021 18日目です。 freeeにjoinしてから早くも14ヶ月がすぎました。freeeでは毎年10月に全社障害訓練をしていて、昨年は入社したてで右も左もわからないままAWS上の本番環境（のレプリカ）に侵入してDBをぶっ壊す役目をさせられたのも良い思い出です*1。 で、上の「CEOに身代金を要求したい」という物騒な相談は、今年の訓練計画の話です。話を持ち掛けてきたのはCIOの土佐。昨年は主要サービスが落ちて、開発チームが対応にあたる中、ビジネスサイドも顧客対応などで訓練参加しましたが、今年はさらに、経営サイドまで巻き込もうというゴール設定がされたわけですね。腕が鳴ります。 ゴールは「CEOに4BTCを要求する」 ゴー
関数や変数のネーミングに悩んだら「codic」に日本語名を入力するとある程度解決するかも
codicとは codicは、日頃、変数名や関数名に頭を悩ませるプログラマのためのネーミング辞書です。 以前は、プログラマ向けの単語辞書といった感じだったのですが、Ver.3からは、「日本語を入力すると、ふさわしい名前を勝手に生成してくれる」という仕様になりました。 例えば関数名を作るのに、「従業員数を取得する」と入力するだけで「get_employee_count」という名前を勝手に生成してくれます。 これだけでも、かなり便利なんですが、codicにはその他にも、プログラミングのための便利な機能が満載だったので、その使い方などを紹介したいと思います。 codicの使い方 codicの主な機能は、日本語を入力すると、勝手にネーミングを生成してくれると言うことです。 ただ、ちょっとした使い方次第で、より便利に利用できるので、その使い方などの紹介です。 基本機能 まずは、基本的な機能、「日本語
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
業務ロジックをデータモデリングはどこまで表現できるか？ - プログラマの思索
「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Zendesk、DynamoDBからMySQLとS3へ移行し、コストを80％以上削減