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

ユーザーの送信から取得された変数に基づいて、テーブルからレコードを検索しようとしています。これは私のクエリです： $field = t('field_data_' . variable_get('tabbed_content_field')); $fieldValue = t(variable_get('tabbed_content_field') . '_value'); $query = db_query('SELECT :fieldValue FROM {:field}', array(':field' => $field, ':fieldValue' => $fieldValue)); ただし、このクエリを実行するたびに次のエラーが発生します。 PDOException：SQLSTATE [42000]：構文エラーまたはアクセス違反：1064 SQL構文にエラーがあります。2行目の '' field_data_field_news_release_date ''付近で使用する正しい構文については、MySQLサーバーのバージョンに対応するマニュアルを確認してください。SELECT：fieldValue FROM {：field}; 配列（[：field] => field_data_field_news_release_date [：fieldValue] => field_news_release_date_value） 私はレコードを正常に取得できます： $query = db_query('SELECT ' . $fieldValue . ' FROM { ' …

7 database 

Q＆AとしてPostgreSQLでDrupal 7を実行しています（多数のノードの挿入/更新といくつかのcontribモジュールを使用）。特定のテーブルに対する特定のpgsqlバキュームポリシーを推奨しますか？

7 7  performance  database 

ノードIDを知っている "vid"の値を取得し、 "vid"が2に等しい行の "name"の値を取得します。 単純なクエリだとしたら、どう書くかわかりません。左結合クエリの書き方がわかりません。 Drupalの「プレーン」SQLクエリは次のとおりです。 $result = db_query('SELECT tid FROM {taxonomy_index} WHERE nid = :nid', array(':nid'=>$nid)); 同等の生SQLクエリは次のとおりです。 SELECT did, name FROM taxonomy_index as ti LEFT JOIN taxonomy_term_data AS ttd ON ti.tid = ttd.tid WHERE vid = 2 and nid = $nid

7 7  database 

突然、ウェブサイトがダウンし（drupal 6.19）、mysqlを起動できなくなりました（クラッシュしたテーブルが多すぎます）。df -hをチェックすると、非常に大きなバイナリログファイルが原因でMySQLパーティションがいっぱいであることがわかりました（バイナリログは1日間のみ保持し、expire_logs_days = 1とします）。binbinログの1つをmysqlbinlogで確認すると、ほとんどのエントリはキャッシュテーブル（cache_form、boost_cache、boost_cache_relationships、cache_contentなど）とセッションテーブル用であることがわかりました。一部のデータは何度も繰り返されます。 ちなみに、私はls -lhを見ていて、bin-logファイルが指数関数的に大きくなりました（1、2分ごとに100Mのファイルサイズの新しいbinlogファイルを取得しました!!） これを引き起こす原因について何か知っていますか？この問題を解決するにはどうすればよいですか？

7 caching  database 

私はのようなDrupal 7関数を使用することにかなり慣れていdb_select()ます。一方でnode_load()、非常に使いやすい、明らかですが、私は多くの場合、それは私が必要としないフィールドを返し、私は（いくつか必要になるフィールドが必要行うというフィールドを提供していないことが判明join得るために、複数可）。 したがって、独自のクエリを作成するnode_load()と、他のクエリと組み合わせて使用するよりもパフォーマンスが向上しますか？それともnode_load()、おそらくキャッシュなどから、何らかのパフォーマンスの向上が見られますか？ 私はMySQLのパフォーマンス問題の専門家とはほど遠いですが、最終的に必要なものの一部のみを個別に取得する複数のクエリを使用するよりも、特定の単一のクエリを構築する方が良いようです（そして私が必要としないものの多く） ）。

6 database  nodes