La réputation de l'appât edit:
Moi et un autre développeur à mon travail avait un tableau blanc avec un "Technologies de qui doit mourir" section, nous aimerions ajouter à. Mime courriel a été là-bas, comme ce fut SQL. Le problème avec ancrée technologies telles que la ces est qu'il est difficile de voir un monde sans eux, il est facile de voir un monde sans eux, mais il est difficile de visualiser un monde avec quelque chose de vraiment mieux.
SQL est un de ces reliques. Il a été initialement conçu pour être tapé dans une base de données à l'aide de requêtes conçu par un homme - d'où le pseudo-anglais structure de celle-ci. Les Machines n'étaient pas destinés à faire des commandes SQL, c'est juste que maintenant que la programmation, notamment avec le web, a une forte dépendance à l'égard des bases de données et SQL est ce qui est l'interface standard pour les bases de données.
Une chose que je suis sûr, c'est que l'obtention d'un langage de programmation pour faire un homme-chaîne de langue qui est transmis à une base de données qui a pour décoder dans un ordinateur format de langue pour comprendre qu'il est à la fois inefficace et dangereux. Le mélange des données et des commandes est quelque chose que vous ne voulez pas faire, comme il est demander de problèmes. Même aujourd'CPU contient un bit NX pour signaler les zones de mémoire de données de sorte qu'ils ne seront pas accidentellement run - causant un crash ou un exploit. SQL injection questions sont légion, et sont le symptôme pas de (seulement) de mauvais programmeurs, mais d'une mauvaise technologie. Nous avons beaucoup de haut niveau de langues (ci-dessus C), de sorte que les dépassements de mémoire tampon n'est plus un problème, mais sont coincés avec un C niveau de langage de base de données conçu au début des années 70.
Vous avez juste besoin de regarder n'importe quel semi-expérimenté en PHP (ou de n'importe quelle langue) du programmeur code. Sans aucun doute, ils utilisent tous une certaine forme d'abstraction SQL bibliothèque à prendre les risques de complications et de loin de l'utiliser. Par exemple, si je veux extraire le contenu d'une ligne, je vais utiliser quelque chose comme ce qui suit:
$row = CMS_SQL::get_row ('pets_table', 'bob', 'name');
Qui va tirer la ligne à partir de pets_table avec le nom de " bob " - en supposant que le nom est unique dans le schéma. À l'aide de véritables SQL que vous avez à faire...
$name = mysql_real_escape_string ($name);
$result = mysql_query ("SELECT * FROM `pets_table` WHERE `name`='{$name}' LIMIT 1");
$row = mysql_fetch_assoc ($result);
Ce qui est assez horrible, surtout si vous devez répéter la même chose beaucoup. Aussi prenons mise à jour des lignes. Le code ci-dessous utilise mon abstraction SQL classe pour modifier le nom du chat de bob à bobby.
$row['name'] = 'bobby'; # Change pet name to bobby
CMS_SQL::update_array ($row, 'pets_table');
Remarque: update_array utilise la clé primaire id si elle est disponible pour suivre la ligne, c'est pourquoi je ne semble pas l'indiquer. Le code SQL de la ci-dessus est bien pire.
Et enfin, d'obtenir une valeur unique à partir d'une base de données:
$cat_colour = CMS_SQL::get_element ('pets_table', 'colour', 'bob', 'name');
Et dans (dangereux) SQL:
$sql = "SELECT `colour` FROM `pets_table` WHERE `name`='bob' LIMIT 1";
$result = mysql_query ($sql);
if (mysql_num_rows ($result) > 0)
{
list ($cat_colour) = mysql_fetch_array ($result);
}
else
{
$cat_colour = false;
}
Comme je l'ai dit, il est très difficile d'envisager une technologie de remplacement pour quelque chose - quelque chose de nouveau a généralement quelques bonnes idées qui ne fonctionnent pas, et il est évident idées qui sont en quelque sorte manqué, mais j'ai vraiment le faire voir à un éventuel abandon de SQL et de se tourner vers le traitement des bases de données comme si elles étaient effectivement des ressources physiques - avec php par exemple éventuellement traiter l'ensemble de la chose en tant que natif de tableau associatif. Je vois aussi des références d'être traités comme des pointeurs de manière transparente: par exemple, si vous êtes de faire un système de commentaire et d'avoir une table appelée "posts" et "utilisateurs" et vous avez un poster colonne sur la table posts qui fait référence à une entrée unique dans les utilisateurs puis la colonne de postes.poster allait être la bonne ligne sur les utilisateurs. La mise à jour, il serait de mise à jour de la ligne des utilisateurs. Pas de jointures, sous-sélectionne ou toute non-sens.
Avec le tout étant traité comme un natif de la structure de données, il permet d'utiliser un langage spécial pour être exécuté le serveur de base de données, ou même du code natif si le compilateur a été particulièrement intelligent, qui vous permet de l'utiliser en natif des conditions plutôt que là OÙ, comme l'ensemble de la OÙ var='val' ET var2='val2', c'est la programmation conditionnelles (comme si l') simplement représenté dans lisible par l'homme SQL.
Il va probablement être un projet open source comme PostgreSQL ou MySQL ou une autre base de données qui permettra d'offrir une classe native pour traiter avec des données non-SQL format pour un site web en langue tels que Ruby, Python, PHP, etc. qui apportera la facilité de traiter avec les indigènes de données et la puissance d'un dédié à SQL server en un seul. Une fois qu'il est standardisé, stable, natif alternative je peux entrevoir ce remplacement SQL pour 99% de la bas de gamme de plates-formes de stockage de données, SQL relégué à haute performance ultra-d'énormes bases de données et les systèmes existants (avant d'être finalement totalement supplanté).
La raison SQL est si répandue, c'est que les gens pensent en termes de SQL lors d'activités - dès que quelque chose vient le long qui permet aux gens de visualiser mentalement le stockage de données et des requêtes en d'autres termes, je pense que c'est jours sont comptés.
Edit: wow, je ne savais pas combien je détestais SQL jusqu'à ce point :)
