2009-07-03 4 views
1

J'ai un code vraiment funky. Comme vous pouvez le voir dans le code ci-dessous, j'ai une série de filtres que j'ajoute à la requête. Maintenant serait-il plus facile d'avoir plusieurs requêtes, avec son propre ensemble de filtres, puis de stocker les résultats dans un tableau, ou d'avoir ce désordre?PHP: requêtes SQL multiples vs un monstre

Quelqu'un at-il une meilleure solution à ce désordre? Je dois être en mesure de filtrer par mot-clé et numéro d'article, et il doit être capable de filtrer en utilisant plusieurs valeurs, ne sachant pas lequel est lequel.

//Prepare filters and values 
$values = array(); 
$filters = array(); 
foreach($item_list as $item){ 
    $filters[] = "ItemNmbr = ?"; 
    $filters[] = "ItemDesc LIKE ?"; 
    $filters[] = "NoteText LIKE ?"; 
    $values[] = $item; 
    $values[] = '%' . $item . '%'; 
    $values[] = '%' . $item . '%'; 
} 
//Prepare the query 
$sql = sprintf(
    "SELECT ItemNmbr, ItemDesc, NoteText, Iden, BaseUOM FROM ItemMaster WHERE %s LIMIT 21", 
    implode(" OR ", $filters) 
); 
//Set up the types 
$types = str_repeat("s", count($filters)); 
array_unshift($values, $types); 

//Execute it 
$state = $mysqli->stmt_init(); 
$state->prepare($sql) or die ("Could not prepare statement:" . $mysqli->error); 
call_user_func_array(array($state, "bind_param"), $values); 
$state->bind_result($ItemNmbr, $ItemDesc, $NoteText, $Iden, $BaseUOM); 
$state->execute() or die ("Could not execute statement"); 
$state->store_result(); 

Répondre

2

Je ne vois rien de particulièrement monstrueux dans votre requête. La seule chose que je ferais différemment est de séparer les termes de recherche.

Ie $ item_list peut être divisé en items numériques et en texte.

alors vous pouvez faire la recherche quelque chose comme:

...WHERE ItemNmbr IN (number1, number2, number3) OR LIKE .... $text_items go here.... 

IN est beaucoup plus efficace et si votre $ item_list ne contient aucune partie de texte ... alors vous êtes juste à la recherche d'un tas de chiffres ce qui est vraiment rapide.

Maintenant, la partie suivante si vous utilisez beaucoup de LIKEs dans votre requête peut-être vous devriez envisager d'utiliser MySQL Full-text Searching.

+0

Pourrais-je également utiliser MATCH .. AGAINST pour effectuer une recherche par numéro d'article? Parce que malheureusement les numéros d'article ne sont pas seulement des chiffres pour une raison abandonnée ... – MackDaddy

2

Votre réponse dépend de ce dont vous avez besoin. L'avantage d'utiliser seulement 1 requête est celui de l'utilisation des ressources. Une requête prend seulement 1 connexion et 1 communication avec le serveur sql. Et en fonction de ce que vous essayez de faire exactement, il faudra moins de puissance SQL pour le faire dans une déclaration que de multiples. Cependant, il pourrait être plus pratique du point de vue des programmeurs d'utiliser quelques instructions sql moins complexes qui nécessitent moins de créer qu'une seule grande. Rappelez-vous, ultimitaly vous programmez ceci et vous devez le faire fonctionner. Cela pourrait ne pas vraiment faire la différence, le traitement de script contre le traitement SQL. Vous seul pouvez faire appel ultime, ce qui est plus important? Je recommanderais généralement le traitement SQL au-dessus du processus de script en traitant de grandes bases de données.

1

Une requête de table unique peut être mise en cache par le moteur SQL. MySQL et ses semblables ne mettent pas en cache les tables jointes. La règle générale pour les performances est d'utiliser des jointures uniquement lorsque cela est nécessaire. Cela encourage le moteur DB à mettre en cache de manière agressive les index de tables et facilite également l'adaptation de votre code aux bases de données objet (plus rapides), comme vous le demandent les services cloud Amazon/Google.