テーブル・DB設計するときの極意 - Qiita
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ テーブル・DB設計は「属性」と「関係」の２つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - Yoshisaurのメモ
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
どのレイヤー（層）でトランザクションを実装すべきか
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
データモデルはドメインモデルに先行する - 設計者の発言
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
Oracle Cloud Infrastructureのアカウントが突然停止したので状況や調査内容を書いていく
Oracle Cloud Infrastructureのアカウント停止発覚 最初にも書いたが、Oracle Cloud上で稼働させているサーバプログラムが応答していないことから、アカウントが一時停止状態にあることが発覚。 急遽停止してしまったサーバプログラムに対しては暫定対応をとり、事なきを得る。 ちなみにダッシュボード上には下記のようにアカウント一時停止の旨が表示されている。 Oracle Cloudアカウントの状況 最初に自身のOracle Cloudアカウントの契約状況を書いておくと、少し前にアカウント自体はトライアルから有料アカウント(Paid Account)にアップグレードが完了している状態。 請求なども想定通りに発生しており、アカウント自体は問題なく運用できていると思っていた。 そのためアカウント一時停止が発覚した際はなぜなのか？という疑問と、突然頭から氷水をかぶったような感
『理論から学ぶデータベース実践入門』の間違いを指摘する - Qiita
『理論から学ぶデータベース実践入門』という本を読んでいて、2章の論理学の説明に多くの誤りを見つけたので指摘しておく。 この本はデータベースについての技術書であり、数学書ではないのでこれらの誤りがこの本の価値を完全に損なうとは思わない。しかし、述語論理に基いてリレーショナルモデルを説明するという趣旨の本である以上、その基礎である論理学の説明が不正確なのは大きな問題である。また著者が論理学の専門家でないなら、専門家にレビューを頼むか、最低でも適切な論理学の教科書へのリファレンスが必要ではないかと考える。 この文章は特定の本を参考にしたわけではないが、以下に定評のある論理学の入門書をいくつか挙げておく。 戸田山和久『論理学をつくる』（名古屋大学出版会） 小野寛晰『情報科学における論理』（日本評論社） 以下、論理学についての誤りのうち比較的大きなものを指摘する。これはすべての誤りのリストではないし
NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 － Publickey
NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？（前編） NTTデータオープンソースDAY2015 現在のシステム構築では、オープンソースのソフトウェアを使うことは当たり前になってきています。PostgreSQLはそうした中で主にエンタープライズ向けのデータベースとして着実に事例を増やしてきています。 その中で、PostgreSQLを大規模なミッションクリティカルなシステムの中で使うには、どのようなノウハウが求められるのか。オープンソースの利用に積極的なNTTデータがその事例を、1月26日に開催されたイベント「NTTデータオープンソースDAY 2015」のセッション「NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは？」で紹介しています。講演内容をダイジェストにしまし
かなり不快だったから書く。
http://b.hatena.ne.jp/entry/excel-databace.hatenablog.com/entry/2014/09/04/094049 かなり不快だったから書く。 当方メーカー、腐れ研究職。品質管理とかもたまにみてる。 雲の上のIT業界の方々の話はこの際関係ない。 Excelは方眼紙じゃねえとかデータベースじゃねえとか Access使えとか、じゃあいいよ、Access使うとして 社内にAccessで作ったデータベースを保守できる人がどれだけいるんですか？ Excelのオートフィルタも満足に使えない人がいるような環境で、 Accessなんてまず購入してインストールさせる段階ですら 稟議なり交渉が必要なのかわかってていってるの？ それでうまく申請が通ってインストールしたとして、 コメント書いた人がExcelから流し込んでデータベース作ります、 いざデータベースできま
データベース設計を学ぶ本: わく☆すたブログ
システム開発を行う時のアプローチとしては，大きく，次の３つのアプローチがあります。 １．プロセス中心アプローチ（POA） ２．データ中心アプローチ（DOA） ３．オブジェクト指向アプローチ（OOA） 昔ながらの、機能やプロセスを中心としたアプローチがプロセス中心アプローチです。そこから，変化しにくい「データ」というものをシステム開発の中心に据えて開発するデータ中心アプローチが考えられました。 オブジェクト指向は，別系統での「オブジェクト指向」という考え方をベースにしたアプローチですが，こちらも最近では普通に用いられています。 データベーススペシャリストは，このうちのDOA，データ中心アプローチをメインに扱います。 試験に良く出てくる，トップダウンアプローチ，ボトムアップアプローチなどでER図を作成していく手法は，DOAです。 ですので，DOAの考え方を学んでおけば，データベースス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
