実践イミュータブルデータモデル — NEWTポイント機能の設計こんにちは、バックエンドエンジニアの飯沼です。かんたんに海外ツアーを予約できるNEWT（ニュート）と、それを支える社内向けのツアー入稿・予約管理システムのバックエンド開発を担当しています。 先日、ツアーの旅行代金の5%分のポイントを還元する「NEWTポイント」をリリースしました。1ポイント＝1円として次回の旅行予約で使えるおトクな機能となっておりますので、海外旅行をご検討の方はぜひご活用ください。ポイント機能の思想やサービスとしての設計についてはPMの藤沼の記事をご覧ください。
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
データベース設計におけるNULL - kawasima
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
表示順という属性を別テーブルに分ける - そーだいなるらくがき帳
最近、この説明を複数回したので記事にする。 要約 普段は 今北産業 派なのだが、3行考えるのが面倒なため、今後は大人の表現を使う。 「今北産業」をスタートアップ語にすると「マジ価値サマリー」になるらしい ちなみにここだけの話ですが、大人語にすると「要約」になります pic.twitter.com/Q8SflvBX7c— ところてん (@tokoroten) 2022年1月24日 画面に表示したい順(以下、表示順）は振る舞いの属性なので分ける 似たような振る舞いに関わる属性は別テーブルにわけると良い 普通に正規化しましょうって話。 表示順をカラムを追加して表現する よくあるテーブルは画面情報と合わせて表示順カラムがあるパターン。 こういうテーブルを作って SELECT * FROM items ORDER BY display_order_number; で表示順に取り出すパターン。 表示順
MariaDB versus MySQL - Compatibility
Replacement for MySQL Until MariaDB 5.5, MariaDB versions functioned as a "drop-in replacement" for the equivalent MySQL version, with some limitations. From MariaDB 10.0, it is usually still very easy to upgrade from MySQL. MariaDB's data files are generally binary compatible with those from the equivalent MySQL version. All filenames and paths are generally the same. Data and table definition fi
イミュータブルデータモデルの極意
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。Read less
マイクロサービス時代に捧ぐ、Railsでの中規模APIサーバ開発のための技術構成 - Qiita
初めまして、qsona (tw) と申します。Ruby on Rails Advent Calendar 2016 6日目の記事になります。 Rails歴は10ヶ月で、もちろんAdvent Calendarへの参戦も初です。 全体的に生意気な内容と思いますが、 じゃんじゃんマサカリ投げてください お手柔らかにお願いします。 はじめに 環境 JSONを返すAPIで、データベースはRDBを想定してます。 あんまり関係ないですが一応、Rails5 (api mode) + MySQLを想定しています。 マイクロサービスとしてのバックエンドに使う技術スタックの必要な要件 マイクロサービスの良いところは、サービスごとに合った別々の技術が使えるということです。 とはいえ、一般的な組織であれば、学習コストの面などから、ファーストチョイスとなる言語があり、普通の要件に対してはその言語を使う、ということにな
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
CockroachDB から覗く形式手法の世界 #CNDT2020 / CloudNative Days Tokyo 2020
CloudNative Days Tokyo 2020 で使用したスライドです。 バグのない分散システムの設計は果たして可能でしょうか？ この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシステムの挙動を数学的に解析する技法で、「ノードが特定のタイミングで故障した場合にのみ発生するバグ」といった再現困難な問題を確実に検出することができます。 本講演では、CockroachDB の事例を通して、形式手法が実世界で活用されている様子をお伝えします。 イベント概要：https://event.cloudnativedays.jp/cndt2020 ブログ記事：https://ccvanishing.hateblo.jp/entry/2020/09/10/044848
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
イミュータブルデータモデル(入門編)
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
グレゴリオ暦？ユリウス暦？ データベースによって異なる、日付時刻型が扱える範囲
前回の記事「Excelだけに存在する日付」では、Excelにだけ存在する、実在しない日付形式について書きました。 今回も日付つながりで、データベースの日付時刻型の話を書きたいと思います。 ほとんどのデータベースは、日付時刻型を持っています。 ところが日付時刻型は、数値型や文字型のようにどのデータベースでもほぼ共通、ということはなく、利用可能な範囲、分解能（秒、ミリ秒、マイクロ秒など…）から内部のデータの持ち方まで、データベースや型によって様々です（「範囲」が決まっているのは、日付時刻型に限りませんが）。 日付時刻型の内部値は、前回お伝えしたとおり「ある特定の日付を基準に、その日付からの経過日数で表す」ものがほとんどかと思います。 前回は「経過日数」と書きましたが、データベースによっては「経過秒数」だったり、現在のOracle Databaseのように全く異なる内部管理を行っている例もあった
MariaDB Products & Tools Downloads | MariaDB
MariaDB Enterprise Server: Enhanced, hardened and secured for mission-critical applications MariaDB Enterprise Server is a hardened version of MariaDB Community Server built for production deployments. It undergoes extensive QA, is configured for production by default and includes enterprise features to improve operating efficiency at scale and support the most secure environments. MariaDB Enterpr
MySQLの照合順序 - Qiita
やってみた MySQLの照合順序、UTF-8の日本語で使える照合順序はいくつかあるけど、 実際にどんなマッチの仕方をするのかわからなかったので、ちょっとやってみた。 ちなみに、MySQLのUTF-8で日本語を扱う場合に使用可能な照合順序はしたの3つ。 utf8_bin utf8_general_ci utf8_unicode_ci 確認したかったのは、半角・全角、小文字・大文字がどんな感じでマッチするのかという事。 ながーいので、結果を utf8_bin キャラクターコードが完全に一致するもののみマッチする。 utf8_general_ci アルファベットの大文字・小文字は区別せずにマッチする。 ただし、区別しない文字は、半角は半角の大文字・小文字、全角は全角の大文字・小文字のみ。 半角小文字と全角小文字同士はマッチしない。 utf8_unicode_ci 下記がマッチする。 アルファベッ
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
ActiveRecordでデフォルトの照合順序を変更する - Qiita
MySQLには文字列の照合順序(collation)というのがあって、MySQL側でのcharset utf8のときのデフォルトの照合順序はutf8_general_ciです。 ActiveRecord::Migrationでは明示的に照合順序を指定しない場合、charset utf8で照合順序utf8_unicode_ciのデータベースを作成しますが、これは少なくとも日本語圏では多くの人が期待する挙動ではないと思われるので注意が必要です。 たとえば、以下のようなファミリーテーブルをrake db:migrateすると # coding: utf-8 class CreateFamilies < ActiveRecord::Migration def change create_table :families do |t| t.string :name t.string :relation
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テーブル設計の考え方とやり方 [入門編]![テーブル設計の考え方とやり方 [入門編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fff34d6fcb76b27f602c88a8a78045329642f395/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5416b70d025345fc95b30d1ec95701b6%2Fslide_0.jpg%3F20931325)
ポイントカードシステムのデータベース開発と評価
Doma