[B! RDB] [2ページ] fuyu77のブックマーク

論理削除がデータを汚している - jfluteの日記

ベクトルの違うデータまあ、それは事実。ただ、履歴をそのまま残したいということも事実。いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータである考えます。でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か

fuyu77 2019/05/15

RDB

リンク

論理削除の必要性をひねり出そうとして失敗した - ネットの海の片隅で

はじめにこのエントリは僕の平凡な考えを淡々と書いたものです。過度な期待はしないでください。あと、部屋は明るくしてディスプレイから30センチは離れて見やがってください。物理削除したくない！外部キー制約を張っていない場合削除したレコードを参照しているレコードがエラーを吐く外部キー制約を張っている場合参照されているレコードは削除できないカスケードで削除すると影響範囲が大きいレコードがあったという事実は記録しておきたい事実は消えない論理削除もしたくない！削除するときにdeletedフラグなどを立てるあらゆるクエリにWHERE deteled = falseとか入ってきて汚い物事は「削除」されるのではない注文は削除されるのではなくキャンセルされる従業員は削除されるのではなく解雇されるじゃあ、どうするの？大雑把に書いてきましたが、このあたりのことがデータの削除は非

fuyu77 2019/05/15

RDB

リンク

【GWにおすすめ】サーバーレス開発部でおすすめされた技術書を17冊紹介します | DevelopersIO

今月入社したサーバーレス開発部の佐藤です。ジョインブログから初めての投稿です。札幌オフィス勤務予定なのですが、札幌にサーバーレス開発部のメンバーがいないため、1ヶ月間、会社の文化になれるために東京の岩本町オフィスに出社しています。前職からの働きかたのギャップが激しいですが、毎日楽しく仕事をしています。先日、サーバーレス開発部のSlackチャンネルで、おすすめの技術書を紹介してくれという雑なポストをしたところ、すごい勢いで技術書が流れてきたので、保存する意味も込めてブログにまとめてみました。おすすめ理由については、サーバーレス開発部の方々に直接聞いたものを載せています。おすすめされた技術書 Webを支える技術 Webを支える技術おすすめ理由当たり前に使っているWebやREST、HTMLなどベースとなる技術の歴史からふりかえっており単純に読み物として面白いです普及している技術の思

fuyu77 2019/04/25

RDB

リンク

『失敗から学ぶRDBの正しい歩き方』と『SQLアンチパターン』｜Koske Kano

巷で話題の﹃失敗から学ぶRDBの正しい歩き方﹄(通称﹁そーだい本﹂: 以下、文字列長の都合でこの呼称を使用します)を読んだメモです。 Webアプリケーションを構築していく時、データの設計や運用の面で﹁こうしておけばよかったー﹂と後から悶々とする場面は多々あるんですが、本書はそれら現場のモヤモヤや失敗の数々に名前を付け、﹁アンチパターン﹂として断罪(！？)していく内容になってます。元々は﹃SQLアンチパターン﹄という、よく似たコンセプトの素晴らしいオライリー本があるんですが、本書でも随所に言及があるので未読の方はまずそちらから手をつけるのがいいかもしれません。ざっくりした内容はそれぞれリンク先の章立てを覗いてみてください。なんとなく雰囲気はつかめるんじゃないかと思います。今回は両者を比べながらゆるーく感想を書いていきたいと思います。両者の守備範囲この2つ、まぁよく似た構成ではあるんで

fuyu77 2019/04/25

RDB
SQL

リンク

カラムの内容でデータの状態管理を行ってはいけない。 - プログラマーm-matsuokaの生存記録

no title no title本来やるべきだったことは、状態をくまなく探し、例えば ENUM として Number を割り当てるなどの設計です。システム全体でその数値が何を意味するかを周知する必要もあるでしょう。周知の代わりに、それぞれの状態に応じた VIEW を合わせて設計するというのも、非常に重要かつ有効な場合もあります。ここで気になるのは、実は同じような ENUM が、すでにアプリケーションコードの方に定義されてないかです。既存アプリがあるなら、その担当チャネルに IRC で呼びかけるか、リポジトリを clone してgit grep してみましょう。だいたいみんな同じ事を考えていて、擦り合わせないと後で後悔します。データの状態を特定のカラムの内容で判別しようという思考停止フラグ。やっていることはDELETE_FLAGをより複雑化させ、多くの人々を巻き込むことで

fuyu77 2019/04/18

RDB

リンク

NoSQL とは?（NoSQL データベースの解説と SQL との比較）| AWS

NoSQL データベースは特定のデータモデル専用に構築されており、最新のアプリケーションに合わせて簡単にスケールできる柔軟なスキーマにデータを格納します。NoSQL データベースは、開発、機能性、パフォーマンスを大規模かつ容易に実現できるという点で広く評価されています。このページには、NoSQL データベースを理解して使用するための参考資料が含まれています。モダンアプリケーションは、NoSQL データベースで解決できるいくつかの課題に直面しています。例えば、アプリケーションは、ソーシャルメディア、スマートセンサー、サードパーティのデータベースなどのさまざまなソースからの大量のデータを処理します。このような異なるデータのすべてが、リレーショナルモデルにきちんと合うわけではありません。表形式の構造を適用すると、冗長性、データの重複、および大規模なパフォーマンスの問題が発生する可能性があります

fuyu77 2019/04/04

RDB

リンク

「表で表すものがリレーショナルデータベース」ではない

これは違う「情報B」の教科書に「データを表で表すものがリレーショナルデータベースである」と書いてあるものがあり、とてもびっくりしました。この定義では表計算ソフトもリレーショナルデータベースを扱っていることになってしまいます。データベースに初めて触れる人も疑問に思うはずです。 1980年代、まだWindowsがなかった時代に dBASE Ⅲ というソフトウェアが販売されていて、「リレーショナルデータベース」であることを売り物にしていました。R-BASE という対抗ソフトも出てこれも「リレーショナルデータベース」であることを標榜していました。それに対して「リレーショナルデータベース」でないデータベースは、日本では「カード型データベース」と呼ばれていました。「リレーショナルデータベース」を謳う製品は高価で使い方も難しそうだったのでほとんど触ったことはありませんでしたが、それでも雑誌の記事など

fuyu77 2019/04/03

RDB

リンク

2023年になっても日本企業の基幹系システムの80％はオンプレミスで商用RDBを使い続ける。臨機応変なデータ分析ツールはExcelであり続ける。ガートナーの予想

2023年になっても日本企業の基幹系システムの80％はオンプレミスで商用RDBを使い続ける。臨機応変なデータ分析ツールはExcelであり続ける。ガートナーの予想ガートナージャパン株式会社は、今後3～5年間で企業の顧客戦略に大きな影響をもたらす動向に注目した、アプリケーション領域における2019年の展望を発表しました。発表にはいくつかの項目が含まれています。その中から3つの予測をピックアップしました。 ■2023年を迎えてもなお、日本の大企業における基幹系システムの80%が商用のリレーショナル・データベース管理システム (RDBMS) を使い、オンプレミスで運用し続けるガートナーが日本企業に行った調査によると、ERPとその中でも汎用化しやすい業務を除いた基幹系システムににおいてはクラウドの採用が進んでいないことが明らかになっています。同様のことが、基幹系システムに利用されるRDBM

fuyu77 2019/03/13

Excel
RDB

リンク

Domo - データ活用プラットフォーム

データの価値を引き出し、ビジネス成果を最大化する基本的なチャートやグラフから、重要な瞬間のビジネスチャンスとアクションを刺激するデータ活用体験を提供します。無償トライアルデモを見る

fuyu77 2019/02/20

RDB

リンク

データベース管理システム - Wikipedia

この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。︵このテンプレートの使い方︶出典検索?: "データベース管理システム" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL︵2023年3月︶データベース管理システム︵データベースかんりシステム、DBMS; 英: database management system︶は、コンピュータのデータベースを構築するために必要なデータベース運用、管理のためのシステム、およびそのソフトウェアのことである。データベースマネジメントシステムとも呼ばれる。概要[編集] かつては、CODASYLが提唱したネットワーク型データモデルのDBMSや、階層型データモデルのDBMS、あるいは初期の非力なパーソナルコ

fuyu77 2018/11/30

リンク

データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub｜若手Webエンジニアのキャリアを考える！

データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本 MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。﹁良いテーブル設計﹂のためには知識と経験が不可欠です。今回は日本 MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。坂井恵︵さかい・けい︶ @

fuyu77 2018/09/18

RDB

リンク

リレーショナルデータベースの仕組み (1/3) | POSTD

リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば﹁リレーショナルデータベース仕組み﹂などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術︵ビッグデータ、NoSQL、JavaScriptなど︶を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？私は開発者として、理解していないものを

fuyu77 2018/08/18

RDB

リンク

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の導入するにあたっての考え方やテクニックを紹介します。

fuyu77 2018/07/08

RDB

リンク

DBのインデックスと複合インデックス - Qiita

データの並び順が社員コード順になっていないので、全件検索し該当レコードを探す動きになる Q:主キーインデックスと普通のインデックスの違いは？インデックスという視点では違いはない。主キーはDBが自動でインデックスをつけ削除不可である。したがって何もインデックスを作成しなくても主キーのインデックスは必ず生成される。 ※主キー順は非常に重要である。上記の社員テーブルにおいて社員コードのみで絞り込む要件しかない場合、1．社員テーブル(主キー順‥所属コード,社員コード) ２．社員テーブル(主キー順‥社員コード,所属コード) ﹃1．﹄の主キーでは主キーインデックスが所属コード、社員コードの順となるため新しく社員コードのみのインデックスを作成する必要がある。しかし﹃2．﹄の主キーなら主キーインデックスが社員順となるため新しくインデックスを作成する必要はない。見た目の区分に合わせて主キーを作りた

fuyu77 2018/05/08

RDB

リンク

インデックスの意味とメリット・デメリット

このインデックスはidカラムと name カラムの値だけを保持し、name カラムの値を昇順に並び替えてデータを保存しています。name カラムの値を検索する時に、元のテーブルを検索するよりもデータ量が少なくまた並び替えも行われているので高速に検索することができます。ではどうやって高速に検索できるようにしているのかについてですが、Wikipediaのインデックスのページを見ても B-Tree 方式や関数方式など色々方法があるようです。そして SQLite ではどのような方式を採用しているのかは分かりませんでした。インデックスを作成することでテーブルとは別に検索用に最適化された状態で必要なデータだけがテーブルとは別に保存されるということを覚えておいて下さい。インデックスのメリットデメリットインデックスを作成しておくと便利ではありますがメリットだけではありません。テーブルとは別にデ

fuyu77 2018/05/08

RDB

リンク

RDBとNoSQLにみるDB近現代史データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！

﹁ユーザー目線﹂のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、﹁テーブル﹂と﹁SQL﹂の発明です。 RDBでは、すべてのデータを﹁テーブル﹂というただ一つのデータ形式によって表現します。テーブルは、見た目が﹁二次元表﹂に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。テーブルが画期的だった点は、もう一つあります。

fuyu77 2017/11/27

RDB

リンク

データベースの用語を理解しよう「テーブル」「レコード」「カラム」「フィールド」とは？ | GMOクラウドアカデミー

2016.04.25 データベースの用語を理解しよう﹁テーブル﹂﹁レコード﹂﹁カラム﹂﹁フィールド﹂とは？用語の意味を知る必要データベースにおける用語 Ⅱ－ⅰ．﹁テーブル﹂ Ⅱ－ⅱ．﹁カラム﹂ Ⅱ－ⅲ．﹁レコード﹂ Ⅱ－ⅳ．﹁フィールド﹂ Ⅰ．用語の意味を知る必要 ①デキる人は、専門用語の使い方が正確ですウェブサイト開発に長く携わっていてしょっちゅう感じるのは、﹁デキる人﹂と﹁普通な人﹂でちょっとした仕事のやり方や使う言葉が違う、ということです。具体的な行動や言葉は時代時代で変わってくるのですが、そうした傾向はいつの時代でもあるようです。今でこそ社内のPCがネットワークでつながっているのは当たり前ですが、平成が始まった頃はそうでもありませんでした。昨日までつながっていたPCやプリンターの接続が切れていることなどしょっちゅうでした。そのような時、普通のエンジニアはネットワークのプロ

fuyu77 2017/10/24

RDB

リンク

データベース列名の名前付け（英単語での）採用例を集めてみた - Qiita

データベースのテーブルやビューなどに指定する列名︵カラム名、フィールド名︶の例を集めてみました。各データベースの、予約語や使える文字種の制限は、ご自身にてご確認ください。国際感覚的にかなりあっていない︵ただし本稿は国内利用を主として書いています︶、スペル間違いや明らかな採用間違い、などがありましたら、是非ご指摘くださいませ。。住所 (county, district, prefecture, province, region, state) の扱いなど、国際的な利用が前提でしたらWeblioさんを参照してみましょう。 ※私は記法の宗教戦争をしたくありませんので、ご自身のお好みにあわせて変換をしてください︵キャメル記法が...スネーク記法が...単数形・複数形など、各チーム・各プロジェクトの規約に合わせてくださいね︶こんなことが大切かと︵テーブルやビューの名前と組み合わせれば︶その