Bueno, vamos a aclarar previamente un par de conceptos: Un id_usuairo no es una sesión, y una sesión de usuario no está definido por si id_usuarios... Son cosas diferentes.
El id_usuario (que en tu caso es redundante), es el identificador de la tabla de usuarios que permite establecer las relaciones entre la entidad Usuario y los datos persistentes que la base tenga en diferentes tablas. Pero como ID del usuario
no identifica en si las acciones realizadas en un mismo período de logueo / deslogueo.
Una sesión y su ID es el el conjunto de interacciones de un usuario en un mismo sistema, desde el momento de su identificación y hasta la terminación de la conexión, que puedan ser consideradas como temporalmente continuas. En ese sentido, las acciones de un usuario en una sesión pueden requerir que se identifique la sesión en la que se realizaron, para lo cual se necesitan obligatoriamente dos datos: 1) un identificador único de sesión, y 2) la fehca y hora en que la accion se produjo.
Nada de esto puede ser soportado por tu modelo de datos. Lde faltan estructuras y atributos para eso.
En segundo lugar, vamos a hacer otra aclaración, para que no volvamos a hablar de este punto: El que los datos en la aplicación lleguen por POST o por GET
es totalmente irrelevante para la base de datos. No importa, porque la base jamás ve el origen de los datos en la web; la base sólo se comunica con el servidor, respondiendo peticiones a un puerto determinado, que peuden ser enviadas por una aplicación en PHP, Java, .Net, o lo que fuese, y MySQL
no lo sabe ni le interesa saberlo. No agrega ni pone nada, y aclarar el origen de los datos es ajenos al SQL. Sólo tiene utilidad para el programador que crea la aplicación, pero no para el MySQL.
¿Se entiende?
Si hay problemas de programación causados por el origen de los datos en web, es tema de otros foros. Acá solo miraremos lo que tenga que ver con estructura de datos y consultas SQL.
Todo lo que tenga que ver con checkboxes, enlaces, sesiones de PHP y demás, que no sean datos puros que lleguen a la base para registrarse en tablas, para l abase simplemente no existen.
¿Se entiende?
Ahora bien, de acuerdo a esto:
Cita: que me arroge todas las publicaciones del usuario del perfil (el usuario lo saco con GET url). Y que me arroge solo los publicos(flag=0), pero en caso que sea privado(flag=1) y la session de ese momento es igual a id_user_origen o es igual a id_user_destinatario cual sea de las dos entonces que tambien me lo arroge aunque sea privado, porque es el que creo la publicacion y al que se lo envio tambien lo tiene que mirar.
hay más condiciones a cumplir que las que dijiste al principio:
Cita: Y que me arroge solo los publicos(flag=0), pero en caso que sea privado(flag=1) y la session de ese momento es igual a id_user_origen
Cita: o es igual a id_user_destinatario cual sea de las dos entonces que tambien me lo arroge aunque sea privado
Lo que nos acercaría a esto:
Código MySQL:
Ver originalWHERE (id_user_origen
= 'usuariologueado' AND flag
= 0) OR id_user_destinatario
= 'usuarilogueado';
Lo que debe quedarte claro es que para poder ver como poner las condiciones debes analizar cuidadosamente para expresarlas como condiciones a cumplir que puedas
diferenciar.
Te aclaro que dominar la logica del WHERE lleva algo de tiempo y bastante práctica. No es raro que los expertos también cometan errores.
te sugiero que reveas tu modelo porque como ya te dije, no soporta en realidad diferenciar las acciones de los usuarios por sesiones, ya que las sesiones no están ni identificadas, ni temporalizadas.
