タグ

データベースに関するcitrus_gingerのブックマーク (29)

  • どうやって校閲記者は調べているか

    「著者から後書きに名前を入れていいか聞かれることはありますが、誤植が後で見つかったらと思うと怖いですね」。引用部分を探す苦労、事実確認はどこまでするか…出版の分野で活躍する校正・校閲者の方々に聞きました。... 「これは会社の財産ですね。ぜひ公開してほしい」 「校閲者や司書は泣いて喜ぶと思いますよ」 毎日新聞の校閲センター内で共有しているインターネットサイトのリンク集のことです。私たちの仕事に合わせて作ってきたので一般にどこまで役に立つか分かりませんが、そのような声をいただいたため、どなたでもアクセスできる部分などを公開することにしました。 このリンク集の始まりは2009年ごろ。米国の雇用統計や消費者物価指数など、一から調べると手間がかかる経済関係の情報を早く調べるためでした。そこからスポーツなどデータが豊富に使われる記事などでもリンクがまとまってあれば便利だということで徐々に分野が広がり

    どうやって校閲記者は調べているか
  • https://kessan.laboneko.jp/

    https://kessan.laboneko.jp/
  • Franchise - 多数のデータベースに対応したSQLノートブック

    SQLを覚えると実務で使える様々なデータを取得できるようになります。毎回同じようなSQLを記述するのが面倒で、テキストファイルに定番のSQLをメモで残している方も多いのではないでしょうか。 そんな方にお勧めなのがFranchiseです。SQLを残しておけるノートブックです。 Franchiseの使い方 メイン画面です。複数のデータベースに対応しています。 結果を地図に描画する例です。 グラフ。線グラフです。 棒グラフ。 並び替えた棒グラフ。 ドットだけ。表示を2カラムにしています。 一般的な一覧表も可能です。 レンジを使ってその時の値を表示するパターン。 メールを取り込んでクエリを投げるパターン。 FranchiseのデータリソースはSQLite/PostgreSQL/BigQuery/MongoDB/Microsoft SQL Server/Oracle/DB2/Teradataなどとな

    Franchise - 多数のデータベースに対応したSQLノートブック
  • なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策|ハイクラス転職・求人情報サイト AMBI(アンビ)

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策|ハイクラス転職・求人情報サイト AMBI(アンビ)
  • 4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回はに載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方はを購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをま

    4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
  • アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)

    毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした! この記事がすごく良かったので、触発されてブログ書く!!! developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき

    アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)
  • IDの設計についてのさらに突っ込んだ議論

    今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり(ブログ書いてないで原稿書けよ>俺)であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で

    IDの設計についてのさらに突っ込んだ議論
  • リレーショナルモデルのドメイン設計についての議論

    リレーショナルモデルを実践するには、ドメイン(≒データ型)を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性(≒カラム)に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

    リレーショナルモデルのドメイン設計についての議論
  • データベースアプリケーション開発を炎上させる負のスパイラル

    毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか? A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ

    データベースアプリケーション開発を炎上させる負のスパイラル
  • データベース技術の羅針盤

    PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)NTT DATA Technology & Innovation

    データベース技術の羅針盤
  • Excelデータを最速でWebアプリ(Heroku)にする<del>10</del>9のステップ

    ローカルには映画の視聴記録とかべ歩きのお店評価とか投資履歴とかガラクタコレクションリストとかの自身の活動記録的なデータが溜まります。そしてどういうわけかそれらのデータは大概表計算ソフト「Excel」の上に置かれているのです。その結果、溜めたはいいが有効に活用されない、場合によっては見ることすらしないという事態に陥ります。それらのデータが来的に置かれる場所が「データベース」であり、その活用によりデータ価値が向上するということに誰も異論はないとしても、データはExcelに置かれるのです。 理由は一つ。そう、データベースは敷居が高いのです。 データベースの敷居が下がれば、みんながローカルのデータをもっともっと大量に公開して世の中はもっと便利になるに違いありません。 まあ、実際のところはよくわかりませんが。 そんなわけで… データベースの敷居を下げるべく、CSVデータを簡単にデータベース化する

  • データベース設計の煩雑な作業を自動化する「ERMaster」

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

  • ドキュメント指向のNoSQLデータベース(CouchDB、MongoDB)編

    書籍紹介 連載は下記書籍から第5章を基に、@IT向けに再構成して掲載しています。 目次 序 章 ビッグデータの時代 第1章 NOSQLとは何か? 第2章 NOSQLのデータモデル 第3章 アーキテクチャの基概念と技術 第4章 HadoopはNOSQL? 第5章 主なNOSQLデータベース製品 第6章 NOSQLデータベースの選択基準 第7章 NOSQLを使うビジネス 連載は書籍『NOSQLの基礎知識』(リックテレコム刊、ISBN:978-4897978871)で解説されている内容から一部を抜粋し、連載向けに一部再編集して掲載したものです。 書籍では、一般にNoSQLと呼ばれている各種データベース技術について、基概念から主要なプロダクトの特性、ベンチマーク結果までを紹介しています。データモデルやアーキテクチャの違いといった基概念から、各プロダクトの特徴を理解できる内容になっていま

    ドキュメント指向のNoSQLデータベース(CouchDB、MongoDB)編
  • SQLアンチパターン - 開発者を待ち受ける25の落とし穴

    3. 諸君は自らの経験からいくらか学ぶことがで きるという、全く愚かな考えであろうが、 余はむしろ他人の失敗を学ぶことで、自分の 失敗を回避することを好む。 ─オットー・フォン・ビスマルク Nur ein Idiot glaubt, aus den eigenen Erfahrungen zu lernen. Ich ziehe es vor, aus den Erfahrungen anderer zu lernen, um von vorneherein eigene Fehler zu vermeiden.

    SQLアンチパターン - 開発者を待ち受ける25の落とし穴
  • Works - データベース接続あれこれ

    ORACLE:OLE DB プロバイダ(ORACLE製) ▲TOP Provider=OraOLEDB.Oracle;Data Source=<接続文字列>;User Id=<ユーザID>;Password=<パスワード> ORACLE:OLE DB プロバイダ(Microsoft製) ▲TOP Provider=MSDAORA;Data Source=<接続文字列>;User Id=<ユーザID>;Password=<パスワード> ORACLE:ODBCドライバ(ORACLE製) ▲TOP バージョンによりドライバ名が変わる点に留意。 Driver={Oracle in OraHome92};DBQ=<接続文字列>;UID=<ユーザID>;PWD=<パスワード>

  • プロが作った黒猫印のフリーソフト 黒猫ソフトウェア工房

    ソフトウェア工房では、現役SEがこだわりのフリーソフトを開発しています。■最新情報 黒 SQL Studio 1.3.10.443 をリリースしました。(2007.10.21)new! 黒 SQL Studio 1.3.10.442 をリリースしました。(2007.10.20) 黒 Excel DBLink 1.2.3.39 をリリースしました。(2007.10.15) 黒 SQL Studio 1.3.10.440 をリリースしました。(2007.9.28) 黒 SQL Studio 1.3.10.438 をリリースしました。(2007.9.19) 黒 SQL Studio 1.3.10.437 をリリースしました。(2007.9.15) ■黒 SQL Studio 黒 SQL Studio は、あらゆるデータベースに接続可能な汎用SQL開発

  • A5:SQL Mk-2 - フリーのSQL開発ツール/ER図ツール

    A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL

  • 名字検索No.1/名字由来net|日本人の苗字・姓氏99%を掲載!!

    名字ランキングデータ提供について 無料で日最大150万人登録のデジタル家系図を作りたい方はこちら!! 2024.7.2 日の紙幣に肖像が描かれた偉人の珍しいレア名字ランキングを発表!! 2024.7.1 今なら名字や系図の文献が大特価で手に入る!! 2024.7.1 戦国村を作ろう!のLINEスタンプ 好評販売中!! 2024.6.19 2024年上半期 名字トレンドランキングを発表!! 2024.6.5 平安時代の有名人珍しいレア名字ランキングを発表!! 2024.5.15 日の歴代ボクシング世界王者の珍しいレア名字ランキングを発表!! 2024.4.10 【2024年4月最新版】各名字の順位・人数データを更新!! 2024.4.10 歴代柔道オリンピックメダリストの名字ランキングを発表!! 2024.4.3 2024年J2・J3リーグ選手の珍しいレア名字ランキングを発表!! 20

    名字検索No.1/名字由来net|日本人の苗字・姓氏99%を掲載!!
  • 【DB概論】正規化の手順

    正規化とは、データを一元管理するための理論です。 1データ1箇所の原則を実現するために、1970年にE.F.Codd氏がリレーショナルモデルの理論として提案しました。正規化の理論は、データの冗長性を排除し、更新時の整合性を維持しやすくすることを目指しています。 具体的には、属性間の関連性を分析し、属性の最適なグループ化を図ることを目的としています。 一般には第3正規化まで行えば十分といわれていますが、来は、あてはまる場合にはきちんと第5正規化まで行う必要があります。 まず、正規化の処理をする際によく出てくる関数従属という用語の意味を復習しておきましょう。 ◎ 関数従属とは ある属性Aの値が決まると他の属性Bの値が一意に決まるとき、「属性Bは、属性Aに関数従属である」(A→B)といいます。 完全従属とは、2の属性A、Bの間でA→Bが成立し、Aが複数の属性の集合で成り立っている場合、Aのいか

    【DB概論】正規化の手順
  • データベースの内部動作を知る

    SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの

    データベースの内部動作を知る