RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
エクセルをデータベースとして使うには、こうすればいいと思うのだけど、なぜ誰もやらないのかな？ - Excel 業務システム
エクセルは罫線ワープロじゃない なんでエクセルをこんな使い方するのだろう？ 毎回、毎回、会議のたびに同じような資料作って、もう疲れました。 データとして管理するなら１件のデータを横一列に入力して、縦向きに連続してデータを繰り返して管理しないといけません。 エクセルは罫線ワープロじゃない ここでやってはいけないこと エクセルのフォーム編集機能は、使えない データベース形式で、管理する 印刷シートに、データをリンクしてはダメ！ 印刷シートは、［印刷作業領域］にリンクします。 エクセルカード HARI の使い方（動画） Excel と Access を連携して使う（動画） Acces と Excel を連携して、本格的なデータベース管理を行うには？ Excel → Access → Azure と移行していく セールスApp KATA（営業支援ノーコードアプリ） ここでやってはいけないこと １．
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
