Rails 7 + MySQLの環境構築をDocker composeで作る - Qiita
二年前にRails 6 + MySQLの環境構築をDocker composeで作るという投稿を書いたが、Rails 7ではWebpackerが廃止されるなど色々と変更点があったので、Rails 7用に書き直した。 Dockerの公式サイトにはRailsアプリケーション用のDocker composeチュートリアルがあるが、少し情報が古くRails 7ではうまく動かなかったので、Rails 7で動かすための方法を載せておく。基本は公式チュートリアルの手順に従っているため、Rails 7用に変更したところを中心に補足を入れている。 DBはPostgresではなくMySQLを使う方法を載せておく。 プロジェクトディレクトリの準備 FROM ruby:3.1 RUN mkdir /myapp WORKDIR /myapp COPY Gemfile /myapp/Gemfile COPY Gemf
グラフDBのNeo4jでカフェのレコメンド機能を実験してみた - オールアバウトTech Blog
お世話になります。オールアバウトのsutchanです。 今回は、"Neo4j“というグラフデータベースを触って遊んでみた話をしたいと思います。 Neo4j（グラフデータベース）とは まず、グラフデータベースとはなんぞやという話から。 グラフデータベースはグラフ構造を持ったデータを扱うのに特化したデータベースです。 グラフ構造は、電車の経路やSNSのソーシャルグラフ、ドラマの人物相関図のようなものと言えば、イメージしやすいかもしれません。 図にあるように、グラフデータベースは、データの実体であるNodeと、それらをつなぐRelationで構成されていることがわかります。 NodeとRelationには、Property（Key-Value形式の付加情報）も付けることができます。 グラフデータベースは、その特徴から、電車の乗換案内や地図アプリの経路探索、SNSの「知り合いかも？」など、レコメン
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
RailsでDBのデータ変更はどこに書く？ - komagataのブログ
productionのデータ変更処理をmigrationに書くとrails_best_practicesに怒られる。 Rails Best Practices | Isolating Seed Data 怖話のコードで言えば下記の様なもの。 # encoding: utf-8 class InsertSeedToSound < ActiveRecord::Migration def up Sound.create!(id: 1, name: "鳥の鳴き声") Sound.create!(id: 2, name: "犬の鳴き声") Sound.create!(id: 3, name: "水滴") Sound.create!(id: 4, name: "カエルの鳴き声") Sound.create!(id: 5, name: "ラジオのチューニング") end def down Sound.d
Railsインストール後：アプリケーションの作成からRspecを使えるようにするまで。 - tkymtk's blog
ディレクトリを作成 $ mkdir <directory_name> そのディレクトリに移動 $ cd <directory_name> アプリのひな形を生成 $ rails new <app_name> 生成したアプリのディレクトリに移動 $ cd <app_name> このとき、$ cd <app_name> --skip-test-unit とオプションを付けると、testディレクトリをつくらないので、 あとでtestディレクトリを消さなくて良い。 テストデータベースの作成 $ rake db:create $ rake db:migrate $ rake db:test:prepare Gemfileを編集し、RspecとCapybaraを導入し、開発環境の構築 Gemfileの最後に以下のコードを追加 group :test do gem 'rspec-rails' gem 'c
C# - macOS ではじめる ASP.NET Core x Entity Framework Core x PostgreSQL - Qiita
Mac で C# の Web 開発ができるようになった! Visual Studio Code (VS Code) で C# を書いて，O/RM の Entity Framework Core (EFC) から PostgreSQL にアクセスし，データベースのレコードを .NET で表示する。すべて macOS 上で可能になったのです。 そうです，Mac で .NET Web アプリ開発がついにできるようになったのです！ 本稿では Mac 版 VS Code 上で C# を書き，EFC から Postgres に CRUD した結果を自動テストコード xUnit.net で検証します。 Postgres のインストールと，VS Code のデバッグ，.NET の Web アプリを配備できる非同期 I/O の Kestrel Web サーバについては本稿の対象外としています。僕が執筆中の薄
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
4. データの挿入、読み出し、更新、削除 | densan-labs.net
4.1. DbContextとエンティティの状態¶ Entity Framework(EF)では，DBへのデータの挿入，読み出し，更新，削除といった基本的な操作はDbContextを通じて行います． Contextという名前から分かるように，DbContextは内部に挿入や更新を行うオブジェクトの状態を保持しています． 例えばデータをDBに挿入する場合，EFでは以下のように記述します． public class Product { public int ProductId { get; set; } public string Name { get; set; } public int Price { get; set; } } public class ShoppingContext : DbContext { public DbSet<Product> Products { get;
DB 設計時のサイズ見積り[最新版] - Qiita
こんにちは、すっかり秋ですね！@yone098 です。 みなさんDBの設計してますか？ DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5
![DB 設計時のサイズ見積り[最新版] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f42e24e40ddeea81bc76c98ccc1f982252cd6b3c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9REIlMjAlRTglQTglQUQlRTglQTglODglRTYlOTklODIlRTMlODElQUUlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTglQTYlOEIlRTclQTklOEQlRTMlODIlOEElNUIlRTYlOUMlODAlRTYlOTYlQjAlRTclODklODglNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWM5ZmIwOTA1Y2UwNjU4NDA0MzRmOTZlMmI2NDFlMGU1%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b25lMDk4JTQwZ2l0aHViJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iZDkzOTdmMGQ3NWNhMGM4M2I3NmMxNjM4ODQ2OWQxMA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-QWJieQ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D6f836c4a275f61471b9e3f73ef123bda)
◆インデックスの構造と内部動作１
データベースの内部構造 非クラスター化インデックスの正確な構造 インデックスの階層数の調査： dm_db_index_physical_stats インデックスを作成しても効果のない列 インデックスが役立たない例 クラスター化インデックス データベースの内部構造 データベースの内部構造 インデックスを理解するには、データベースの内部構造を理解しておくことが重要です。まずは、データベースの内部構造から理解していきましょう。 データベースは、次のように「データ ファイル」（.mdf）と「トランザクション ログ ファイル」（.ldf）の 2種類で構成されます。データ ファイルには、テーブルやデータ、インデックス、ビュー、ストアド プロシージャなどが格納されます。 ページとヒープ データ ファイルは、内部的には、「ページ」という 8 KBの大きさで区切られています。ページは、ディスク入出力の単位で
Web制作フローが「完璧」にわかる資料や流れのまとめ | コムテブログ
TL;DR 受注前、制作フロー、安定収益源の保守方法まで「作って終わりにしない」Web 制作の一連の流れを記載しておきます。社内だけじゃなく、これから独立する人、フリーランスの方も必見です。 オリエンテーション／受注前 １．書類テンプレート一式 オリエンテーションにおけるヒアリングでは、後に作成する提案・見積書に必要となる質問を用意しておきます。自社の説明をする時は、せっかちなクライアントさんもいるので、だらだら話さず、ポイントを抑えてわかりやすく説明します。ヒアリングした後は、議事録にメモし社内共有。必要な書類（ヒアリングシート／企画書／提案書／業務委託書／見積書／契約書）など一式まとめてますので、書類系のテンプレートは以下で。 企画・提案・見積・納品・契約などのテンプレ・知識まとめ２３ ２．見積もりの目安と計算方法 例えば項目を作るとき１．項目／２．内容／３．設計(人日)／４．製造(人
第1回 全文検索エンジンgroongaを紹介します！ | gihyo.jp
今回から始まった隔週連載groongaでは、groongaを使いたくなるような情報を隔週毎にお届けします。 groongaとはGitHubで公開されているオープンソースの全文検索エンジンです。大量にある文書の中から目的のキーワードを持つ文書を高速に見つけることができます。 groongaのロゴ©groongaプロジェクト 第1回目である今回は、この連載についてとgroongaの特徴を紹介します。 この連載について まず、この連載について説明します。 この連載は「読者の皆さんがgroongaを使いたくなる！」ことを目指しています。そのために、次の2点の情報を次回から交互にお届けします。 groongaの利用事例の紹介 利用事例に関連した役立つ情報の紹介 利用事例を紹介することで、「あそこでも使っているなら自分も使ってみようかなぁ」とか「こんな使い方をしているなら自分も使ってみようかなぁ」と
ありがちなデータベース設計を共有することができる『DB Patterns』 | 100SHIKI
これまたマニアックな苦笑。 DB Patternsでは、ありがちなデータベース設計を共有することができる。 フォトアルバムだったらこういうテーブルがあって、こことこのキーが共有されるとかなんとかをグラフィカルに見ることができる。 まだ投稿も少ないし、いろいろ突っ込みどころもあるのだが、初心者のうちは確かに悩むところだし、便利なサービスではなかろうか。 ユーザー登録をするとすでにあるパターンをForkしたり、新しく作ったりもできるようだ。興味がある方はどうですかね。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
404 | Developers.IO
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018
** YAPC::Asia Tokyo 2011 RejectConf 本当は難しいフレンド・タイムライン処理
Ruby2.0.0とRails4をためしてみた | | Scimpr Blog
dbpatterns.com