Question de conception de base de données très simple

Question

Disons que j'ai un service de messagerie entre les utilisateurs, avec des messages publics et privés. J'aimerais que les «publics» soient visibles par tous, et que les «privés» soient VRAIMENT privés. Lequel des deux modèles serait le meilleur?

a)

Ayant une base de données unique, appelée "messages" avec les colonnes

• id
• expéditeur
• récepteur
• horodatage
• valeur
• vie privée (ce qui serait une valeur booléenne, 0 pour privé et 1 pour le public)

Ou b)

Avoir deux bases de données, l'un appelé "messages_public" et d'autres appelé "messages_private" avec le mêmes colonnes suivantes

• id
• expéditeur
• récepteur
• horodatage
• valeur

Je sais que la deuxième approche est redondant, mais il est plus sûr dans le sens que dans le cas d'une erreur est survenue, les messages privés ne seraient pas accidentellement affichés pour tout le monde (ce qui serait un désastre ), ai-je raison? Dans le premier cas, en revanche, il pourrait vraiment. Une erreur simple dans la requête SQL pourrait échouer à filtrer les messages privés, et il afficherait chacun.

Answer 1

Je pense que ce soit la conception serait bien, même si je préfère le premier parce qu'il élimine les redondances.

Dans votre cas, la sécurité va descendre à votre code d'application, qui va devoir garantir que les messages privés ne sont fournis aux utilisateurs appropriés. S'il y a un défaut dans le code de l'application, l'un ou l'autre schéma de base de données pourrait exposer les données privées aux mauvais utilisateurs.

Answer 2

Les deux peuvent échouer, cela dépendra de votre erreur! C'est pourquoi vous testez d'abord. La deuxième approche peut échouer aussi facilement que la première si les noms des tables vous rendent confus, puisque la structure est la même.

Answer 3

Mieux vaut tout garder dans un seul tableau. Dans tous les cas, scinder les tables n'a probablement pas les avantages que vous pourriez penser qu'il fait de toute façon.

• Si un attaquant fonctionne un moyen de vider la totalité de la table publique, puis ils vont probablement être en mesure d'obtenir messages_private à vider ainsi.

• messages_private contient pas seulement mes propres messages privés, mais tout le monde est , donc si cette erreur hypothétique se produit alors que je suis à la recherche à mes propres messages privés, il finirait par le dumping de toute façon tout le monde.

Answer 4

Vous pouvez envisager une base de données avec une table, mais utiliser une vue de base de données pour vos messages publics, quelque chose comme:

puis sélectionnez vos messages publics des public_messages voir. Cela pourrait aider à éviter les erreurs de programmation maladroites où private = false est omis des instructions select dans le code.

Answer 5

S'ils doivent être "VRAIMENT privés" par opposition à "un peu privé" ou "privé-ish", utilisez l'approche de table unique, cryptez les messages privés et décryptez-les à la sortie. De cette façon, si vous fluff, alors le pire qui se passe est que vous affichez le charabia.

Mais finalement, je dirais juste ne faites pas d'erreurs.

Answer 6

Je pense que le second serait l'enfer à utiliser et les applications ci-dessus seraient plus sujettes aux bogues qu'avec le premier. BTW, la sécurité doit être gérée au niveau de l'application, c'est-à-dire la configuration du serveur et de l'application utilisateur elle-même. Bonne chance!