はてなブログには、同じ話題でつながる「グループ」があります。まずはこちらの「2024年開設ブログ」に入りましょう。同時期に始めたブログとつながることができます。 「2024年開設ブログ」のグループ
![はぶにっき - [Goya][Cuppa]Goyaを継ぐ者](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
はぶにっき - [Goya][Cuppa]Goyaを継ぐ者
はてなブログには、同じ話題でつながる「グループ」があります。まずはこちらの「2024年開設ブログ」に入りましょう。同時期に始めたブログとつながることができます。 「2024年開設ブログ」のグループ
ID or not ID - A.R.N [日記]
おぉ、ガチだ。 [RDBMS]複合主キー？ 18:57 ･･･まだそんなこと言ってる人いるのか。 id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。 いや、お互いものすごく優秀で有名な方だし大人なのでガチの勝負はしてくれないとは思うのだけれど、ぜひ世の多くのさまよえるSEのためにガチンコ勝負して決着つけてくれんかなぁ。てゆうか、今回の案件でもID派（＝私）と複合主キー派（＝モデラー）でもろに喧嘩してるし、前のプロジェクトでも他の人が同じようなことやってたし、さらに前の案件でも(w そろそろ、IDを使うべきかそうでないかくらいベストプラクティスを決めてほしいなぁと思う今日この頃*1。 たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるよ
![ID or not ID - A.R.N [日記]](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b9f5dd5b04b969b65543d66daeabf09d2f67327/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127064254481%2F17680117127064335398%2F1555805246)
「何かと便利」な設計方針？ - 設計者の発言
データベースの「正規化崩し」の理由としてしばしば聞くのが「何かと便利なのでこのようにした」である。 たとえば、次のような関数従属要件があるとする。 これが、たとえば次のように物理設計される。 なぜテーブルＤやＤＦに、本来並ばなくていい項目がごそごそ並ぶのかと問うと、「これらを置くことで、関連テーブルを読まずに値が手に入る。プログラムがシンプルになるし、何かと便利だろうから」と説明される。 この種の設計の妥当性を吟味するためには、「継承属性」と「スナップショット項目」の違いを理解しておく必要がある。継承属性とは、あるテーブルから見て多重度１のテーブル上に載っている項目（テーブルＤから見ればＡ、ＤＦから見ればＡとＤ）のことで、インデックスを張るとか参照キー制約を組み込むといった明確な目的にもとづいて実装される。実装された継承属性については、もともと載っていた項目の値が変更されたら、すかさず値を
ACIDデータとACIDフリーデータ - 公園音楽のすゝめ
データベースのデータベースたる所以は、データが壊れないことだと言ってもいいでしょう。ACIDで保護されたデータですね。ところが最近考えているのは、ACIDで保護されない、ACIDフリーデータ。例えばあるメソッド内でしか使用されないローカルオブジェクトで、もしメモリに十分な余裕がある場合には、メモリ上で操作されるようなデータが、メモリ制限によってディスクを利用しなければならないようなデータに使いたいわけです。 トランザクションで保護されるということのメモリ・I/Oアクセスのオーバーヘッドはかなりのものです。つまりこれらのオーバーヘッドを取り除くことで、非常に高速で省メモリなアクセスが可能になります。db4oはオブジェクトデータベースですから、ACIDで保護されたオブジェクトとACIDフリーなオブジェクトは互いに参照を持っていても何ら問題ないようにします。例えばこんな風に： objectCon
ハッカーの金鉱脈「SQLインジェクション」の正体
最近，「SQLインジェクション」の危険性について語られる機会が増えているが，SQLインジェクションの正体，その問題点，そしてそれを防ぐための方策について詳しく理解している人はまだ多くない。ここでは，SQLインジェクションとは何かを明確に定義し，どのようにして行われるかを説明し，SQLインジェクションから組織を守る方法を読者に伝えることによって，この状況を改善したい。 SQLインジェクションとは何か SQLインジェクションとは，アプリケーションに含まれるコーディング・エラーが原因となって引き起こされるぜい弱性，または欠陥である。SQLインジェクションは，ユーザーが入力したデータを使ってアプリケーションがSQLステートメントを作成し，それをSQL Serverに送信して実行する場合に発生する。この欠陥が及ぼす影響は，コーディング・エラーの性質によって様々である。 具体的に言うと，その影響は，エ
IDがあっても、event からコードを削除してはいけない - 極北データモデリング
盛り下がってきたけど、今かすかにID論が熱い！ 渡辺氏がIDについて懸念していることに自分もよく引っかかるので、自戒のメモ。 コードはfactだから削除しちゃダメ ウチで持っているECサイトのパッケージでは、受注明細テーブルに、商品マスタから商品名をコピーして保持している。 商品名は時々変わるので、何かの方法で「販売時点の商品名」が取れるようになっていないと、お客さんに送った納品書と、 システムの受注履歴表示画面とで、商品名が違ってしまうから。 「コードは不安定で外部キーにはなり得ない」という立場に立つなら、コードも名前と同じ意味で、resource から event にコピーする必要がある。 商品コードを外部キーにするトラディショナルな設計では、商品コードは 商品マスタの当該レコードを指すポインタ 受注というイベントに属するfact（商品名とかと同じ） の２つの意味を持っている。 ID導
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
pylori*style wiki - MigrationによるDB管理
Migrationとは Migration とは、Railsで使うデータベースの管理機能で、テーブル作成・カラ ムの追加/変更などの作業を一元管理できます。SQL でスキーマを書くのでは なく、Rails独自の記法(Rubyの文法の範囲内)を使ってDB管理を行います。以 下のようなメリットがあります。 スキーマのバージョン管理ができる rake コマンドでスキーマのバージョンアップ/ロールバックが可能 データベースに依存しない書き方ができるので、他のデータベースに切り替えるのが容易 対応しているデータベース 現在、対応しているデータベースは MySQL, PostgreSQL, SQLite, SQL Server, Oracle です。 今後、対応DBは増えていくと思います。最新情報は、 http://api.rubyonrails.org/classes/ActiveRecord/Mi
楽々ERDレッスン 第1回：「お持ち帰りご注文用紙」編：CodeZine
はじめに システム構築においてデータベース設計は不可欠です。そこで多くの方がデータベースの設計技法について書籍で学んだりするのですが、なかなか身についたと感じられないことも多いのではないかと感じます。 その理由は、実務で任せられる機会というのが少ないからというのが大きなものとして挙げられます。データベース設計というのは、やはり重要な箇所ですから自然と経験のある人に任せられることが多いのが実態です。しかもデータベース設計を担当するのはプロジェクト全体の中でもごく少数だけになりますから、なかなかチャンスが巡ってきません。 しかし、それを嘆いているばかりではスキルが身につかないのも道理です。そこで身近にあるものを何でも手当たり次第にデータベース設計のネタにしてしまうことで、コツコツと地力をつけていこうというのがこのシリーズの主旨です。 合言葉は、「表組みを見たらERDを描け！」 。では、
HSQLDBのデバイス搭載可能なDBとしての妥当性 - 公園音楽のすゝめ
最近、HSQLDBをデバイス搭載可能なデータベースとして使えるかどうかという調査を行う機会がありましたので、ご紹介しようと思います。 HSQLDBの最新版1.8.0.4を利用 プロファイリングを実行して、 ポイントになるソースコードの調査 ＊よくHSQLDBがディスクフラッシュを十分に行っていないため、耐障害性が無いのではと言われていましたが、 SET WRITE_DELAY FALSE; でcommit時にflushを強制的に実行させることが可能です ====================================================== 「耐障害性について」 ・クラッシュリカバリのアルゴリズムにそもそも欠陥があります http://www.hsqldb.org/doc/guide/apc.html ・CHECKPOINTメソッド自体も耐障害性が十分考慮されていない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
getstartcscape.ps
oracleでテーブル定義の取得の仕方に関して MySQLではshow full columns from *テ... - Yahoo!知恵袋
http://www.buena-idea.net/~hironobu/postgresql/p-2-05.html
not found
はてなブログ | 無料ブログを作成しよう
not found
not found
web.paulownia.jp - JDBC ドライバと接続 URL
Efficient data transfer through zero copy
db4o in Japanese : 2006年6月度ニュースレター