この本について｜Fullstack Next.js と Stripe Checkout で実装するサブスクリプション課金
Rust で SQLite を再実装している - kawasin73のブログ
セキュリティを盾に一点突破。どうもかわしんです。最近 Rust で SQLite を実装してます。 以前の記事で HTTP Parser を Rust で実装しようとしたものの、すでに実装されていたので断念しましたが、いい題材を見つけました。SQLite です。開発中のリポジトリはこれです。 github.com 今の時点では、Read Only で1つの WHERE 句を持った SELECT 文しか処理できないですが、以下の機能を実装しています。 sqlite3 で生成された database ファイルの読み取り (cursor.rs, btree.rs, record.rs) SQL 文の解析 (token.rs, parser.rs) テーブルとインデックスのメタデータのパース (schema.rs) 動的なファイルの読み込み (pager.rs) SQL クエリとスキーマ情報を元に
気軽に始めてみよう！クラウド時代のデータウェアハウス超入門 | DevelopersIO
始めに 私は8年ほど前に情報処理試験でデータウェアハウスというものがあるということを知りました。当時は4択問題で問題文に 意思決定支援 というキーワードが出てきたら何なのかよく分かんないけど選択してました。それからずっと興味がありながら実物に触ったことはなかったのですが、クラウド型のデータウェアハウスが登場し触る機会を得ることができました。以前に比べデータウェアハウスはかなり身近なものになってきたのではないでしょうか。弊社でもAmazon RedshiftというAWSのサービスを利用した案件が増えてきています。 クラスメソッド、POSデータ数十億件をリアルタイム分析する基盤を「Amazon Redshift」「Tableau」で開発 この記事ではデータウェアハウスの知識から分析ツールを使ってAmazon Redshiftに接続するところまで簡単にまとめています。実際にどんなものか、触ったこ
ER図とは？書き方やテクニックをわかりやすく解説
ER図（Entity Relationship Diagram）とはデータベース設計における代表的な設計図のことです。 システムを設計する手法としては他にもUMLなどの技法がありますが、ER図はDOA(データ中心アプローチ）の技法であり、作成したER図がそのまま物理データベース上に変換できることから、データベース設計手法におけるデファクトスタンダードとなっています。 大規模なシステム開発においてはER図は必要不可欠です。そこで、これからはじめてER図を書くという方向けに、ER図の概要や書き方、テクニックなどについてご紹介します。 ER図のEはエンティティ（Entity）の略で、Rはリレーションシップ（Relationship）の略です。つまりER図は「エンティティ＝モノ」と「リレーションシップ＝関係」の組み合わせでシステムのデータやデータ間の処理構造を設計します。例として「顧客が商品を注文
データベース（RDB）設計の進め方！ - Qiita
はじめに RDBMSのデータベース設計（論理）の進め方について、設計をする際、こんなことを考えながら進めているなというのを出来るだけ分かり易く記載したいと思います。ただDB設計には「これが正解」というものはあまりなく、要件の必要条件を満たしているDB設計が正解となります。とは言え、考慮した方が良い点や注意点などはありますので、何から始めたら良いの？という方の参考になれば幸いです。 ※論理設計の話しなのでカラムの型やサイズ、パフォーマンス（INDEX（索引））などは割愛しますが、実際にDB設計をする際は、使用するDBの型・キー・制約の種類は事前にインプットを入れておいた方が良いです。 DB設計におけるポイント 先にDB設計を行う上で重要だと思うポイントをあげます。 要件・仕様を理解しているか（要件を満たすテーブル／カラムが揃えられるか） 要件にない（見えにくい）システムの仕様を想像できるか
データベースのドキュメント管理を自動化した話 - estie inside blog
こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie（オフィス探しサービス）とestie pro（不動産事業者向けデータプラットフォーム）の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する
SchemaSpy • Database Documentation Built Easy.
Get Started Welcome in SchemaSpy we will do the best to simplify documentation process of your database. When you start using SchemaSpy you can build your documentation in continuous process > java -jar schemaspy.jar -t mssql05 -dp C:/sqljdbc4-3.0.jar -db DATABASE -host SERVER -port 1433 -s dbo -u USER -p PASSWORD -o DIRECTORY Installation Process of installation is very simple because SchemaSpy i
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
NoSQLデータモデリング技法 · GitHub
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
業務システムにおけるロールベースアクセス制御 - Qiita
RBACの基礎 業務システムの権限制御の基本形はロールベースアクセスコントロール(RBAC)です。簡単化すると、以下のようなモデルです。 Subject(システムユーザ)は、複数のRole(ロール)を持っている。 Role(ロール)は、Permission(権限)のセットからなる。 Permission(権限)は、オペレーション(許可される操作)のセットからなる 具体的に、Redmineでの例をみてみましょう。 ユーザにはデフォルトで「管理者」「開発者」「報告者」のロールが割当可能である。 「報告者」ロールは、「Add Issues」の権限をもつ。 「Add Issues」の権限をもつユーザは、「Issueの新規作成」ができる。 このモデルをRedmineでは、以下のように表現しています。 Redmineは1人のユーザを、複数のプロジェクトに異なるロールでアサインすることができるので、上記
Firebase Realtime DBを実践投入するにあたって考えたこと - Qiita
Firebase Realtime DBを実践に投入する Databaseと聞くと、これから利用しようとする**Firebase**がmBaaSであることを忘れてついREST(Client Server Model)で考えてしまいがちですが、大前提はMobile Platformなので、一度REST、RDBの考え方は捨ててみてください。 RDBの考え方を引き継いだままでは、Firebase Realtime DBの最善の設計はできないと考えています。 そして、RDBの考え方を引き継いだままFirebase Realtime DBを理解しようとすることが、導入の一つの障壁となっていると思っています。 ぜひ頭をリフレッシュしてFirebase Realtime DBの見方を変えてみてください。 この記事では、Firebase Realtime DBの導入するにあたっての考え方やテクニックを紹介
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでデータベース設計(ER図)を管理する｜白露｜note
論理テーブル設計と物理テーブルデータ設計の違いや特徴 – Rainbow Engine
https://qiita.com/yuichi_komatsu/items/3aae65c362b2a57f6fbf