タグ

MySQLに関するYassLabのブックマーク (3)

  • Railsのid列は必ずしもきれいな連番にはならないんですよ、という話 - Qiita

    はじめに Railsでモデルを作ると、テーブル定義上のid列(プライマリーキー)はデフォルトで自動的に連番が付与されるカラム(auto increment値)になります。 とはいえ、idにしたからといって必ずしも連番になるとは限りません。場合によっては「歯抜け(ギャップ)」が発生こともあります。 そのため、「idの最大値=そのテーブルの件数」になるとは限りません。 つまり、こういうデータが作成されることもありうる、ということです(たとえ一度もDELETEされなかったとしても)。 id name

    Railsのid列は必ずしもきれいな連番にはならないんですよ、という話 - Qiita
    YassLab
    YassLab 2025/03/27
    "PostgreSQLの場合、id列はbigserial型になります。この型ではギャップが発生するケースがあることがマニュアルに明記 / 「テーブルへ正常に挿入されていないにも関わらず、シーケンスの値を"消費してしまう"」ケースに該当"
  • DHHが考えるRailsのバリデーション設計

    3行まとめ 単純なバリデーション(必須・範囲・文字数など)はHTMLDB制約、CHECK制約があれば十分であるというのが最近のDHHの主張。 SQLiteではCHECK制約が少し貧弱なため、制約変更の可能性がある場合は従来通りアプリケーションでもバリデーションした方がいい。 Rails初心者はDHHの方法をそのまま採用するのはやめた方が良い。 調べたきっかけ 最近DHHがonce.comでのCampfireをはじめとしたプロダクトで、NULL制約やDB制約で防げるようなRailsのモデルのバリデーションを積極的には利用しないでいるという主張をしている。 DHHの主張を要約すると以下のようになる。[1] HTMLでのバリデーションが優れている 例えば、input type=“email” にしておくとブラウザで勝手にメールアドレス形式ではない場合にエラーにしてデータ送信をしないようにしてく

    DHHが考えるRailsのバリデーション設計
    YassLab
    YassLab 2025/03/26
    "SQLiteについてはRailsもSQLiteのプロダクション利用も積極的に勧めていきたい側面もあるし、MySQL等に比べるとCHECK制約の機能が少し貧弱な側面もある / 不安ならアプリケーションのバリデーションをサボるのはお勧めしない"
  • ClinPeer Railsプロジェクトの技術選定(2025年版) - メドピア開発者ブログ

    こんにちは。サーバーサイドエンジニアの三村(@t_mimura39)です。 こちらでご案内した通り、弊社で新しくリリースした「ClinPeer」の裏側をご紹介します。 tech.medpeer.co.jp 今回はClinPeerのバックエンドについての簡単なシステム概要と選定技術の紹介編です。 2024-2025年にrails newをした新鮮なRailsプロジェクトの様子をお楽しみください。 目次 システム概要 rails stats Gemfile 技術選定 Ruby Ruby on Rails Puma ActionPack::CloudfrontViewerAddress Trilogy SolidQueue SolidCache Kaminari Async::HTTP::Faraday Ueki Jb Nokogiri Blazer ActiveHash Flipper Log

    ClinPeer Railsプロジェクトの技術選定(2025年版) - メドピア開発者ブログ
    YassLab
    YassLab 2025/02/26
    "MySQLアダプタとして「Trilogy」/ ネイティブライブラリへの依存が少なく、今後のメンテナンス性の観点からもtrilogyが優れていると判断し迷いなくこちらを採用 / 今のところは不具合・デメリットなど特になく安定して稼働"
  • 1