タグ付けされた質問 「database」

私が働いている会社でMySQLを使用しており、Ruby on Railsを使用してクライアント向けアプリケーションと内部アプリケーションの両方を構築しています。 ここで働き始めたとき、私は今まで遭遇したことのない問題に遭遇しました。実稼働サーバー上のデータベースはLatin-1に設定されます。これは、ユーザーがUTF-8文字をコピーして貼り付けるユーザー入力があるたびに、MySQL gemが例外をスローすることを意味します。 私の上司は、これらのほとんどが印刷できない文字であるため、これらの「悪い文字」と呼び、それらを取り除く必要があると言います。これを行う方法はいくつかありますが、最終的にはUTF-8文字が必要な状況に陥りました。さらに、特にこの問題について読んだ唯一の解決策はデータベースをUTF-8に設定することであるように思えるので、少し面倒です（私にとって理にかなっています）。 Latin-1に固執することについて聞いた唯一の議論は、印刷できないUTF-8文字を許可すると、MySQLでテキスト/フルテキスト検索が台無しになる可能性があるということです。これは本当ですか？ UTF-8ではなくLatin-1を使用する他の理由はありますか？それが優れており、よりユビキタスになることは私の理解です。

65 database  mysql  ruby-on-rails  utf-8  ascii 

データベースをより効率的に使用するためには、データベースがどのように機能するかを学ぶ必要があり、私の学習方法はそうすることです。 独自のデータベースシステムを作成したい。私はクエリを使用してファイルを解析する擬似データベースを作成することには言及していません。これは、単にクエリ言語を備えたファイルシステムインターフェイスです。データベースエンジンの実際の構造について話しています。そして、私が念頭に置いているのはリレーショナルでも文書指向でもないので（それが存在する場合は「ノード指向」です）、可能な限り抽象的で高レベルのリソースが必要です。 それでは、どのように作成しますか？どのリソース/チュートリアル/本を読んで理解できますか？ 言語は少しでも重要ではありません。理想的には、コードは特定の言語に結び付けられるのではなく、概念を説明するための擬似コードになりますが、何でもかまいません。私はグーグルで問題について何も見つけることができませんでした（私はこのテーマについて非常に文盲であるため、正しい検索を入力していないだけかもしれません）。 そのようなリソースが利用できない場合、クライアントを作成する方法について何かが少なくとも正しい方向への一歩になると思います。

65 database  database-development 

私は非常にイライラする必要があるかどうか、または何がわからない。大規模なデータベースに対して300を超えるクエリを独力で構築し、後で見つけられるように命名規則を開発しました。私のオフィスの他の誰もクエリの作成方法を知りませんが、昨日、すべてのクエリの名前が変更されたことを知りました。私は今、物事を見つけるのに非常に苦労しています。 私は責任者と話をしましたが、彼女はすべてを軽視しました。彼女はもっと簡単に見つけられるように名前を変更したと言いました。残念ながら、私はそれらを構築、編集、および保守する方法を知っている唯一の人であり、彼女がそれらを見つける必要がある唯一の理由はクエリをテストすることでした。新しい命名規則はまったく意味をなさないため、開発プロセスで後方への一歩を踏み出したように感じます。 私が理解しようとしているのは： 1）私は過剰反応していますか？ 2）これを処理する最良の方法は何ですか？私はこれを上司に話すのは嫌いですが、昨日同僚と話した後、彼女は何も悪いことをしていないように感じていることをすでに伝えることができます。

63 database  sql  access 

重複の可能性： Web「サーバーレス」アプリケーションの作成 そこで、Stack Exchangeクローンを構築し、CouchDBのようなものをバックエンドストアとして使用することにしたとしましょう。組み込みの認証とデータベースレベルの承認を使用する場合、クライアント側のJavaScriptが公開されているCouchDBサーバーに直接書き込むことを許可しない理由はありますか？これは基本的にCRUDアプリケーションであり、ビジネスロジックは「投稿者のみが投稿を編集できる」で構成されているため、クライアント側のものとデータベースの間にレイヤーを配置する必要はほとんどありません。CouchDB側で検証を使用して、誰かがガベージデータを入れていないことを確認し、ユーザーが自分の_userデータしか読み取れないようにアクセス許可が適切に設定されていることを確認します。レンダリングは、AngularJSのようなものによってクライアント側で行われます。本質的には、CouchDBサーバーと多数の「静的」ページを用意するだけで十分です。サーバー側の処理は一切必要なく、HTMLページを提供できるものだけが必要です。 データベースを世界中に公開するのは間違っているように見えますが、このシナリオでは、アクセス許可が適切に設定されている限り、その理由を考えることはできません。Web開発者としての私の本能に反しますが、正当な理由は考えられません。それで、なぜこれは悪い考えですか？ 編集：同様の議論がここにあるように見えます：Web「サーバーレス」アプリケーションの作成 編集：これまでのところ素晴らしい議論、そして私は皆のフィードバックに感謝します！CouchDBとAngularJSを具体的に呼び出す代わりに、いくつかの一般的な仮定を追加する必要があるように感じます。だからそれを仮定しましょう： データベースは、非表示のストアからユーザーを直接認証できます。 すべてのデータベース通信はSSL経由で行われます データ検証をすることができます（多分？べきではありません）データベースによって処理され 管理機能以外に私たちが気にする唯一の承認は、自分の投稿の編集のみが許可されている人 誰でもすべてのデータを読み取ることができます（パスワードハッシュを含む可能性があるユーザーレコードを除く） 管理機能は、データベース認証によって制限されます 誰も管理者ロールに自分を追加できません データベースは比較的簡単に拡張できます 真のビジネスロジックはほとんどありません。これは基本的なCRUDアプリです

62 javascript  architecture  database  security  couchdb 

上司と一緒にデータベースを実装する必要があるプロジェクトに近づいています。私たちは非常に小さな新興企業なので、職場環境は非常に個人的なものです。 彼は以前に私に会社のデータベースの1つを与えてくれましたが、RDBMSの学校で教えられた（そして読んだ）ものに完全に反しました。たとえば、ここには1つのテーブルで構成されるデータベース全体があります（独立したデータベースごとに）。これらのテーブルの1つは20列以上の長さであり、コンテキストのために、1つのテーブルの列名の一部を次に示します。 lngStoreID | vrStoreName | lngCompanyID | vrCompanyName | lngProductID | vrProductName ポイントは、エンティティデータ（名前、サイズ、購入日など）を保持する個々のテーブルが必要な場所であり、データベースごとにすべてを1つの大きなテーブルに押し込みます。 この設計を改善したいのですが、適切に正規化されセグメント化されたデータモデルが実際にこの製品を改善する理由がわかりません。私は大学のデータベース設計に精通しており、その方法を理解していますが、これが実際にデータベースを改善する理由はわかりません。 優れたリレーショナルスキーマがデータベースを改善するのはなぜですか？

61 database  relational-database 

今日の私の同僚は、アプリケーションのすべてのクエリを調べ、それに応じてインデックスを追加することを提案しました。 私たちのアプリケーションはまだリリースされていないため、これは時期尚早な最適化だと思います。ライブになったら遅いクエリを監視し、それに応じてインデックスを追加することをお勧めします。 データベースを設計する際の一般的なコンセンサスは何ですか？新しいクエリを作成するたびに一致するインデックスを追加する必要がありますか？それとも、それがどのように進行するかを監視して確認する方が良いでしょうか？

61 database  database-design  indexing 

私はリレーショナルデータベースでかなりの作業を行ってきましたが、優れたスキーマ設計の基本概念はかなりよく理解していると思います。私は最近、DBが高給コンサルタントによって設計されたプロジェクトを引き継ぐことを任されました。私の腸の本能-「WTF ??！？」-保証されていますか、それともこの男は私の天才であるかのような天才ですか？ 問題のDBは、従業員からのリクエストを入力するために使用される社内アプリです。そのほんの一部を見るだけで、ユーザーに関する情報と、行われているリクエストに関する情報が得られます。私はこれを次のように設計します： ユーザー表： UserID (primary Key, indexed, no dupes) FirstName LastName Department リクエスト表 RequestID (primary Key, indexed, no dupes) <...> various data fields containing request details UserID -- foreign key associated with User table シンプルでしょ？ コンサルタントは次のように設計しました（サンプルデータを使用）。 UsersTable UserID FirstName LastName 234 John Doe 516 Jane Doe 123 Foo Bar …

61 database  sql  schema 

データベースファイル（スクリプトなど）をソース管理する必要がありますか？もしそうなら、それをそこに保持し、そこで更新する最良の方法は何ですか？ データベースファイルをソース管理する必要もあります。開発サーバーに配置して、誰でも使用でき、必要に応じて変更を加えることができるからです。しかし、その後、誰かがそれを台無しにした場合、それを取り戻すことはできません。 ソース管理上のデータベースに最適なアプローチは何ですか？

57 database  version-control 

アプリケーションのバックアップ状況を改善しようとしています。DjangoアプリケーションとMySQLデータベースがあります。Gitでデータベースをバックアップすることを提案する記事を読みました。 一方で、データとコードのコピーを同期させておくので気に入っています。 しかし、Gitはデータ用ではなくコード用に設計されています。そのため、コミットごとにMySQLダンプを比較する多くの余分な作業を行うことになります。保存する前にファイルを圧縮しても、gitはファイルを差分しますか？ （現在、ダンプファイルは100MB非圧縮、bzip圧縮時は5.7MBです。） 編集：コードとデータベーススキーマの定義は既にGitにあります。これは実際にバックアップすることを心配しているデータです。

57 database  git  mysql  django 

Youtubeを例として使用したいと思います。彼らはの形式のIDを使用しますPEckzwggd78。 単純な整数を使用しないのはなぜですか？ またはimgur.com- 9b6tMZS画像やギャラリーなどのIDも使用します。連続した整数ではありません。 なぜ整数（特に連続した整数）を使用しないのですか？ どのような場合、整数の代わりにそのような文字列IDを使用することが賢明な決定ですか？

54 database  database-design  web-services 

ユーザーがさまざまなウィッシュリストにアイテムを追加できるウィッシュリストシステムに取り組んでおり、ユーザーが後でアイテムを再注文できるようにする予定です。これをデータベースに保存して高速で混乱を起こさない最善の方法については本当にわかりませんものをきれいにするため）。 最初にpositionコラムを試しましたが、アイテムを移動するときに他のすべてのアイテムの位置の値を変更する必要があるのは非常に効率が悪いようです。 自己参照を使用して前の（または次の）値を参照する人を見てきましたが、繰り返しますが、リスト内の他の多くの項目を更新する必要があるようです。 私が見た別の解決策は、小数を使用し、それらの間の隙間にアイテムを貼り付けるだけです。これはこれまでの最良の解決策のように思えますが、より良い方法が必要だと確信しています。 通常のリストには最大で約20個程度のアイテムが含まれ、おそらく50個に制限されます。並べ替えはドラッグアンドドロップを使用し、おそらく競合状態などを防ぐためにバッチで実行されますajaxリクエスト。必要に応じて（Herokuで）postgresを使用しています。 誰にもアイデアはありますか？ 助けてください！

54 database  database-design  mongodb  postgres 

最小数のテーブルでデータベース構造を作成する必要がありますか？ すべてが1か所に収まるように設計する必要がありますか、それともテーブルを増やしても大丈夫ですか？ とにかく何かに影響しますか？ 私の友人がmediaWikiのデータベース構造を変更したため、この質問をしています。結局、彼は20個のテーブルの代わりに8個しか使用していなかったので、それを行うのに8か月かかりました（大学での割り当てでした）。 編集 私は答えを次のように結論付けています：ケースが例外的になるまで、テーブルのサイズは重要ではありません。この場合、非正規化が役立つ場合があります。 答えてくれてありがとう。

52 database  database-design 

1週間、NoSQLデータベースについて学んでいます。 NoSQLデータベースの利点と、それらが優れている多くのユースケースを本当に理解しています。 しかし、多くの場合、NoSQLがリレーショナルデータベースを置き換えることができるかのように記事を書きます。そして、頭を動かせない点があります。 NoSQLデータベースは（多くの場合）キーと値のストアです。 もちろん、（JSON、XMLなどでデータをエンコードすることで）すべてをキーと値のストアに保存することは可能ですが、多くの場合、特定の基準に一致するデータを取得する必要があるという問題がありますユースケース。NoSQLデータベースでは、効果的に検索できるキーは1つだけです。リレーショナルデータベースは、データ行の任意の値を効果的に検索するように最適化されています。 そのため、NoSQLデータベースは、コンテンツで検索する必要がある永続的なデータには実際には選択できません。または、私は何かを誤解しましたか？ 例： Webショップのユーザーデータを保存する必要があります。 リレーショナルデータベースでは、すべてのユーザーをusersテーブルの行として、ID、名前、国などとともに保存します。 NoSQLデータベースでは、各ユーザーを自分のIDをキーとして、すべてのデータ（JSONなどでエンコードされた）を値として保存します。 したがって、特定の国からすべてのユーザーを取得する必要がある場合（何らかの理由でマーケティング担当者が彼らについて何かを知る必要があります）、リレーショナルデータベースでは簡単に行えますが、NoSQLデータベースではあまり効果的ではありません。すべてのユーザーを取得し、すべてのデータを解析してフィルターします。 私はそれが不可能だとは言いませんが、それははるかにトリッキーになり、NoSQLエントリのデータを検索したい場合はそれほど効果的ではないと思います。 この国に住んでいるすべてのユーザーのキーを格納する国ごとにキーを作成し、この国のキーに保管されているすべてのキーを取得することで特定の国のユーザーを取得できます。しかし、この手法により、複雑なデータセットはさらに複雑になります。SQLデータベースへのクエリほど実装が難しく、効果的ではありません。ですから、本番環境で使用する方法ではないと思います。またはそれは？ そのようなユースケースを処理するために、何かを誤解したり、いくつかの概念やベストプラクティスを見落としたりしたかどうかは、本当にわかりません。たぶん、あなたは私の声明を修正し、私の質問に答えることができます。

51 database  database-design  sql  nosql  relational-database 

マイクロサービスアーキテクチャの各サービスには独自のデータベースが必要であることを理解しています。しかし、独自のデータベースを持つということは、実際には、同じデータベースインスタンス内に別のデータベースを単に持つことを意味しますか、それとも文字通り別のデータベースインスタンスを含むことを意味しますか？ これにより、私はデータベースの共有を意味するのではなく、これはノー・ノーであり、むしろデータベースのインスタンスです。 たとえば、AWSを使用していて3つのサービスがある場合、単一のRDSインスタンスで各サービスに3つのデータベースを作成しますか、3つのサービスのそれぞれで独立して使用されるデータベースを含む3つのRDSインスタンスを作成しますか？ 単一のRDSインスタンスで複数のデータベースを使用することをお勧めする場合、次の理由により、独立したサービスを持つという目的を無効にします。 RDSインスタンスのリソースはサービス間で共有されます。特定の時間にデータベースの使用量が多い可能性のあるサービスAは、同じRDSインスタンス上で異なるデータベースを使用するサービスBに影響しますか？ すべてのサービスは、そのRDSインスタンスのデータベースバージョンに依存します。

50 architecture  database  microservices  service 

ブログを構築していて、投稿やコメントが必要だとします。そこで、自動インクリメント整数「id」列を持つ「posts」テーブルと、外部キー「post_id」を持つ「comments」テーブルの2つのテーブルを作成します。 次に、おそらく最も一般的なクエリを実行します。クエリとは、投稿とそのコメントをすべて取得することです。リレーショナルデータベースはかなり新しいので、私にとって最も明白なアプローチは、次のようなクエリを作成することです。 SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments FROM posts WHERE id = 7 これにより、必要な投稿のIDとコンテンツ、および配列（JSONで使用するようなネストされた表現）にきちんとパッケージ化されたすべての関連するコメント行が得られます。もちろん、SQLおよびリレーショナルデータベースはこのようには機能せず、最も近い方法は、「投稿」と「コメント」の間の結合を行うことです。これにより、多くの不必要なデータの重複が返されます（同じ投稿情報が繰り返されます）すべての行で）、つまり、データベースをまとめて処理するためと、ORMですべてを解析して元に戻すための両方の処理時間が費やされます。 ORMに投稿のコメントを熱心に読み込むように指示した場合でも、最善の方法は、投稿に対する1つのクエリをディスパッチし、次にすべてのコメントを取得する2番目のクエリをディスパッチしてからクライアント側にまとめることです。また非効率的です。 リレーショナルデータベースは実証済みのテクノロジーである（地獄、私よりも古い）こと、そして何十年にもわたって膨大な量の研究が行われていることを理解しています。そして、それらには本当に正当な理由があると確信しています（そしてSQL標準）は、そのように機能するように設計されていますが、上記で説明したアプローチが不可能な理由はわかりません。私は、レコード間の最も基本的な関係の1つを実装する最も単純で明白な方法であるように思えます。リレーショナルデータベースがこのようなものを提供しないのはなぜですか？ （免責事項：私は主にRailsとNoSQLデータストアを使用してwebappを書いていますが、最近Postgresを試しました。実際にそれが大好きです。リレーショナルデータベースを攻撃するつもりはありません。ただ困惑しています。） Railsアプリを最適化する方法や、特定のデータベースでこの問題を回避する方法を尋ねるのではありません。私は直感に反し、無駄に思えるのに、なぜSQL標準がこのように機能するのかを尋ねています。SQLの元の設計者が結果をこのようにしたかったという歴史的な理由がいくつかあるに違いありません。

46 database  sql  rdbms  query