2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。Read less
イミュータブルデータモデルの極意
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。Read less
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
HowTo: Management Studio を使ってトランザクションログファイル (ldf) のサイズを小さくする方法
神谷 雅紀 Escalation Engineer 「ログファイルが大きくなってディスク領域を圧迫し始めているので、ファイルサイズを小さくしたい」という内容の問合わせは今でも多く寄せられます。今回は、SQL Server Management Studio GUI を使って、トランザクションログファイルのサイズを小さくする手順を紹介します。 ここに記載した方法で、トランザクションログファイルのサイズを小さくしたいという状況のほとんどに対応可能だと思います。 ここに記載した方法でトランザクションログファイルのサイズを小さくできない場合は、おそらく、トランザクションログファイルのサイズを小さくする前に、レプリケーションやミラーリングのトラブルシューティングなどが必要になるでしょう。 ステップ 1 : データベースの復旧モデルを確認する 復旧モデルが「単純」かそれ以外かによって、以降の手順が違っ
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
なぜBTreeがIndexに使われているのか - maru source
※この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル CREATE TABLE user ( id INT UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX (id) ); idカラムにIndexを張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます（特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう？？ Indexとはその名の通り索引を意味します。特定のカラムの索引を作成しておくことで検索を高速化します。 (本の最後によみがな順で単語が並べられたりしています
Amazon RDSを参考にしたとりまチューニング
Amazon RDSを参考にしたとりまチューニング 1. Update 2010/7/21 Amazon RDSを参考にした とりまチューニング 2016/08/19 関西地区PostgreSQL勉強会 株式会社ロックオン 三原俊介 1 2. Update 2010/7/21 自己紹介 2 3. 2012.04 株式会社ロックオン入社 インフラユニット 現在 マーケティングPF 開発部 主にインフラ全般、開発環境の改善、 ロックオフの管理人などなどやってます 三原 俊介– Shunsuke Mihara 自己紹介3 4. 始める前のアンケート4 質問: みなさんDBのチューニング経験はありますか 1. PostgreSQLを使ったことがある方 2. PostgreSQLのチューニングをしたことがある方 3. MySQLを使ったことがある方 4. MySQLのチューニングをしたことがある方
SQL Server 2012 の T-SQL 改善
原文(投稿日：2012/03/19)へのリンク SQL Server 2012 の T-SQL には，ANSI の FIRST_VALUE と LAST_VALUE のサポート，FETCH と OFFSET による宣言的データページング，.NET の構文解析および書式設定機能など，多数の改善が行われている。 フェッチとオフセット SQL Server でサーバサイドページングを実装しようとする場合，現状では命令的なテクニックを使用することが多い。結果セットを一時テーブルに読み込んで行番号を付け加えて，そこから必要な範囲を選び出す，というような方法だ。その他 ROW_NUMBER と OVER パターンを使用したもう少し現代的な方法や，カーソル処理に固執したものも一部にはある。これらのテクニックは難しくはないが，いずれも処理時間を要したり，エラーが発生しやすかったりする。さらに開発者それぞれ
SQLのインデックスとそのチューニングについてのオンラインブック
開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQL、Oracle、SQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 DB2Use The
T字形ER データベース設計技法 - それはBooks
見た目は確かに教科書っぽい感じがします。「データベース設計技法」とタイトルにあるので、論理設計もしくは物理設計に関する書籍かと思うかもしれません。しかし本書は、教科書でもないし、DB設計の技術書でもありませんでした。 本書は、「ビジネスドメインの解析手法」を学ぶものです。T字形ER手法という考え方を用いて、ビジネスの現場をモデル化する手法を学べます。ページ数も140ページ少々と少なく、見開きでひとつのタイトルを解説しているため、とてもわかりやすく理解しやすいです。 T字形ER手法では、テーブルを「リソース」と「イベント」という区別で扱います。概念の違いですので、物理設計には関係ありませんが、ビジネス解析(要求分析)の段階では、とても重要になってきます。 オブジェクト指向設計に通じるところもあり、本書で説明している概念を理解すると、ビジネスドメインでのデータの見方というのがしっくり来ると思い
capsctrl - T字形ER手法（TM）
お絵かき（構文論）のみに終始している。 その人の価値観で異なるお絵かきをしている。 30年前のインデックス（によるファイルアクセス）の概念でデータベース設計を行っている。 1つの手法を使って、「事業解析」「データ構造設計」「プログラムのI/O化」の3つを同時に実現する。 ここでモデル（データ構造）とは 指示規則（意味論）＋生成規則（構文論） TM構文論 TM'（ダッシュ）意味論 TMの限界 コード体系が悪すぎたらモデルにも影響してしまう。 「プログラムのI/O化」といっても良くて70%の実現。 モデルはプログラムに対して強制力がない NESTED-IFが出たらプログラムを中止させること NULLの存在を認めている コッドの関係モデルは、ドメインの直積でタプルのセットを構築する。 その場合、nullの入ったタプルが存在することになってしまう。 nullの正確な意味は、不定(undefined
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
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/fc0061ee00d6c47d46312cbc48ee3fd02c9cc805/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-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9REIlMjAlRTglQTglQUQlRTglQTglODglRTYlOTklODIlRTMlODElQUUlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTglQTYlOEIlRTclQTklOEQlRTMlODIlOEElNUIlRTYlOUMlODAlRTYlOTYlQjAlRTclODklODglNUQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWU2ZDI5ZDViYzUwMTY3ZDBiNTEyM2RiNTQ5ZDAwM2Vm%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQweW9uZTA5OCU0MGdpdGh1YiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZjcyZDE3MzM3ZmQ5MmRkNjRkMWY2YjM1YjI0OTAxNGQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Da0b7ab789a5ccfc1b34355e1b9cbed70)
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
Analyzing CPU traces from Linux with PerfView - Vance Morrison's Weblog - Site Home - MSDN Blogs
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
データベースに携わることは人類に貢献するということ―データベース界のラスボス登場！―喜連川優教授
「喜連川といえばデータベース。ずーっとデータベースをやってきました」とデータベース一筋の喜連川先生。その出発点を探ろうと、専攻を選んだ当時を尋ねようとすると「いまより悲惨でしたよ」と言う。 当時コンピュータに関係する学科となると「Electrical Engineering」で、主流は通信だった。中学生のころ「“体育館一面に並ぶコンピュータと書いた記事”を新聞で目にした」という世代である。人工知能や仮想現実などまだまだ先のこと。当時はコンピュータを専門にしようとすること自体が亜流だった。「未来がどれだけあるか分からない」―当時はそのくらい注目度や期待が薄いという意味で「悲惨」だそうだ。 そんなに不確実なものを選んだのはなぜかと尋ねた。先生は「人生、思い通りになるものは少ないですから」と話し始めた。 「ぼくは車の運転が下手でね。車は“こうやって動かす”と分かっていても、雨が降ったら滑ったりす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ＳＤＩ
SQL Azure でテーブルのサイズを取得
SQLServerのテーブルやプロシージャーのメタ情報を取得する方法 - Qiita
ソーシャルゲームDBの�危機回避
