Mensajes

Citar
SELECT * FROM Reservaciones WHERE entrada NOT BETWEEN '2010-01-07' AND '2010-03-20'

Pero con esto, solo miraría si el día 7 de enero y 3 de marzo está reservado, pero... y si da la casualidad que alguien reserva del 6 de enero al 8 de enero y del 18 de marzo al 25 de marzo?

Las evaluaciones BETWEEN indican un rango total o sea, si tu dices:

NOT BETWEEN '2010-01-03' AND '2010-01-20'

Esta condicion dice, que te retornara todos los registros que NO esten dentro de la fecha desde '2010-01-03' hasta '2010-01-20' Se evalua completo.. desde .. hasta. Ahora si en su lugar quieres saber cuales SI estan reservadas dentro de la fecha desde el dia 03 de Enero al 20 de Enero (Esto incluye todas las habitaciones reservadas a partir del dia 03,04,05,06,07...etc hasta el dia 20 de Enero) utilizarias entonces:

SELECT * FROM table WHERE entrada BETWEEN '2010-01-03' AND '2010-01-20'

En vez de NOT BETWEEN usas BETWEEN.

Si al contrario tu unicamente quieres conocer que habitaciones estan reservadas el dia 03 y dia 07 de Enero solamente esos 2 dias no los dias que estan entre ellos dos, usarias:

SELECT * FROM tabla WHERE entrada IN('2010-01-03','2010-01-07')

Ahora si tu quieres saber que habitaciones estan reservadas desde el dia 03 de Enero al 15 de Enero y desde el dia 5 de Marzo al 25 de Marzo.

SELECT * FROM tabla WHERE entrada BETWEEN '2010-01-03' AND '2010-01-15' AND '2010-03-05' AND '2010-01-25'

Ahora si tu solamente quieres saber las fechas de Reservacion de un cliente en especifico, ahi tu table Reservaciones debera crecer jejejejeje agregandole el campo cliente con su respectivo ID.

Hola.

Siento mucho no haberme expandido en lo antes explicado, realmente tenia mucho suenio  cuando postee esto.

Pero te sirve de guia.

WoW ^TiFa^, sorprendente, muchas gracias, lo que pasa es que no puedo estar todos los días actualizando la base de datos, pero ya sabría hacer eso automático

Lo positivo de las bases de datos relacionales (Al menos las que yo conozco) tienen disponible internamente un CRON  con esto puedes crearte una tarea programada cada 24 horas que se ejecute 1 sola vez, asi mantendras actualizadas de forma automatica el campo 'faltan' para cada fecha ya reservada. Si usas un motor sin esta capacidad, tendrias que dar uso del Sistema Operativo y programar una tarea (un script) que se conecte cada 24 horas a la DB una sola vez y actualize dicho campo 'faltan'.

Entonces la única pega que tengo es lo de las relaciones, a ver, yo nunca hice relaciones (excepto en access), uso PHP+SQL y veo el resultado en PhpMyadmin, pero relaciones te refieres como en access? Es que nunca hice eso...

Ahhhh... no se como relaciona access los asuntos    aqui tendrias que explicarme.

Yo, para reservar, si me dice:
Habitación normal, del día 1, al día 15, pues miraría en la tabla "Reservaciones" la primera habitación si está libre entre esas fechas(mirando si está libre, el día, 1, el día 2, el día 3...), sino, pasaría a la siguiente, así escaneando todas hasta encontrar alguna libre.

Pues suponiendo que quieres ver que habitaciones no estan reservadas desde la fecha '2010-01-07' a la fecha '2010-03-20' (Basandome en el ejemplo de las tablas que postee anteriormente) Seria algo como:

SELECT * FROM Reservaciones WHERE entrada NOT BETWEEN '2010-01-07' AND '2010-03-20'

No lo he probado... pero seria mas o menos algo asi, asi te retornaria todas las habitaciones que NO tienen reservaciones desde el dia 07 de Enero hasta el dia 20 de Enero del 2010. Sino te retorna nada, esto indica que desde el 07 de Enero al 20 de Enero no hay ninguna reservacion hecha, por lo que tienes libres todos esos dias en cualquier habitacion para poder reservar.

Hola.

Lo mas que se me ocurre a estas horas de la noche    son 4 tablas.
3 para cada juego de habitacion (Ultra, Normal, Super) y 1 tabla 'padre' que se encarga de mostrar los dias, fecha, y habitaciones elegidas a permanecer y salir. Me explico (Aunque este ejemplo obvie la tabla Super... pero te vale el ejemplo solo es agregar la tabla Super):

Código (sql) [Seleccionar] Expandir



mysql> describe Normal;
+---------------+------------+------+-----+---------+-------+
| Field         | Type       | Null | Key | Default | Extra |
+---------------+------------+------+-----+---------+-------+
| codigo_normal | char(2)    | YES  | MUL | NULL    |       |
| inicial       | date       | YES  |     | NULL    |       |
| final         | date       | YES  |     | NULL    |       |
| id            | tinyint(4) | YES  |     | NULL    |       |
+---------------+------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> describe Ultra;
+--------------+------------+------+-----+---------+-------+
| Field        | Type       | Null | Key | Default | Extra |
+--------------+------------+------+-----+---------+-------+
| codigo_ultra | char(3)    | YES  | MUL | NULL    |       |
| inicial      | date       | YES  |     | NULL    |       |
| final        | date       | YES  |     | NULL    |       |
| id           | tinyint(4) | YES  |     | NULL    |       |
+--------------+------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> describe Reservaciones;
+---------+------------+------+-----+---------+-------+
| Field   | Type       | Null | Key | Default | Extra |
+---------+------------+------+-----+---------+-------+
| codigo  | char(3)    | YES  |     | NULL    |       |
| entrada | date       | YES  |     | NULL    |       |
| dias    | tinyint(4) | YES  |     | NULL    |       |
| faltan  | tinyint(4) | YES  |     | NULL    |       |
| id      | tinyint(4) | YES  |     | NULL    |       |
+---------+------------+------+-----+---------+-------+
5 rows in set (0.00 sec)



Hay que hacer una relacion de las entidades si decides no usar motor InnoDB con FK. Si decides usar Myisam tendrias que crear TRIGGERS para mantener actualizada la data entre la tabla hijo-padre... bien (Tambien deberas indicar cuales son los indices porke los he obviado para el ejemplo... tengo un poco de suenio )

Ahora observa la data en mis tablas:

Código (sql) [Seleccionar] Expandir



mysql> select * from Reservaciones;
+--------+------------+------+--------+------+
| codigo | entrada    | dias | faltan | id   |
+--------+------------+------+--------+------+
| A1     | 2010-01-07 |  -12 |     -6 |    1 |
| A1     | 2010-03-20 |   -5 |    -71 |    2 |
| A2     | 2010-07-20 |   -8 |   -128 |    3 |
| B2     | 2010-09-20 |   -7 |   -128 |    1 |
| B1     | 2010-05-20 |  -10 |   -128 |    2 |
| B2     | 2010-02-14 |   -6 |    -38 |    3 |
+--------+------------+------+--------+------+
6 rows in set (0.00 sec)                     

mysql> select * from Ultra;
+--------------+------------+------------+------+
| codigo_ultra | inicial    | final      | id   |
+--------------+------------+------------+------+
| B2           | 2010-09-20 | 2010-09-27 |    1 |
| B1           | 2010-05-20 | 2010-05-30 |    2 |
| B2           | 2010-02-14 | 2010-02-20 |    3 |
+--------------+------------+------------+------+
3 rows in set (0.00 sec)                         

mysql> select * from Normal;
+---------------+------------+------------+------+
| codigo_normal | inicial    | final      | id   |
+---------------+------------+------------+------+
| A1            | 2010-01-07 | 2010-01-19 |    1 |
| A1            | 2010-03-20 | 2010-03-25 |    2 |
| A2            | 2010-07-20 | 2010-07-28 |    3 |
+---------------+------------+------------+------+
3 rows in set (0.00 sec)



Ya que para reducir un poco la redundancia, califique las habitaciones por codigo  habitacion Normal = A1,A2,A3, etc... habitacion Ultra = B1, B2, B3, etc... y podrias crear tu otra tabla de habitaciones Super con C1, C2, C3 como codigo de referencia    asi sabras diferenciar en la tabla padre de que habitaciones se esta hablando.

Ahora te preguntaras como yo, inroduje en la tabla padre 'Reservaciones' los dias a durar hospedado alguien en un hotel, o cuantos dias le faltan a partir de la fecha actual para ingresar al hotel (En este ultimo campo 'faltan' deberas actualizarlo diariamente, ya que cada dia que pasa le queda 1 menos para que se hospede el visitante). Todo lo hice con una consulta SQL extremadamente pesada para el motor... (Estoy un poco vaga para hacer TRIGGERS) Pero aqui te va un ejemplo.

* Primero inserto datos en la tabla Normal o Ultra
* Luego hago:

Código (sql) [Seleccionar] Expandir


mysql> insert into Reservaciones values('B2','2010-02-14',(select datediff(inicial,final) from Ultra where id = 3),(select datediff(current_date,final) from Ultra where id = 3), 3);


Espero que se capte mas o menos la idea... es un mero ejemplo, obviamente podria desglosarse hasta en 5 tablas distinta las relaciones... pero yo las reduje en 4 (3 tablas habitaciones , 1 tabla padre)

Me alegro sobremanera que pudieses resolver Ari 

el proposito era intentar guiarte a una solucion, y me alegro que hayas dado con una.

la logica que entendi del limit fue la siguiente, segun las pruebas, el primer valor es de donde se partira (este sin contarlo) y el segundo cuantos registros mas contar ascendientemente. un poco enredado pero asi lo entendi

Digamos que efectivamente seria asi, el primer valor es de donde se parte y el segundo cuantos registros mas contar ascendientemente como dices  enredado ciertamente, pero esa es la idea 

Exacto WHK aunque no conoci tu sistema, si comprobaste que funcionaba asi perfecto  pero para evitar eso que dices del disclosure en PHP (Y para evitarte restrinccion de envio de data entre el cliente - servidor de MySQL por dar uso de TEXT con la variable max_allowed_packet, y que luego se te trunque la data porque esta variable asi lo especifica) Mayor control con CHAR o VARCHAR

Como dije cuestion de gustos personales, todos tenemos uno.

Napk, desde MySQL 5.0.3 VARCHAR viene soportando un maximo de 65,400 mas o menos caracteres. Mis ejemplos son relativos, coloco CHAR(15) porque son eso ejemplos de tablas con registros chiquitos    Ahora tengo una condicion personal, si es algo que yo asumo sobrepasara de 50 bytes (Una direccion por ejemplo) pues me voy con VARCHAR porque su tamanio es variable no fijo ni constante, pero si yo se que el estandar de un primer nombre no ocupa mas de 15 o 20 caracteres, pues para nombre lo ideal seria CHAR(20).

Porque CHAR y no VARCHAR... porque me gusta cuidar la integridad de mis datos     que aunque aca influya tambien el motor de almacenamiento, si no me veo en la necesidad de dar uso de un motor transaccional por las funcionalidades que tiene y el consumo que exhige, tengo entonces yo que intentar cuidar la integridad de mis datos. Y si un tipo de dato puede ayudarme a cuidar mis registros chiquitos, le saco el provecho que requiero.

VARCHAR...simula VARCHAR como un sistema de archivos Ext2 o FAT32    donde la data se va insertando en distintos bloques sin orden alguno y dejando aveces algun bloquecito en medio vacio    todo desfragmentado ahi, ocupara menos espacio de HD en un datafile, pero prefiero que me ocupe mas bytes de disco una data constante organizada en un motor no transaccional para data chiquita, que tener que cuidar espacio del disco en un motor no transaccional con una data desfragmentadora.

Cuestion de gustos de cada quien asumo 

Que crimen... un tipo TEXT para un nombre...    pobre optimizador del motor.

Bueno fijate, puede ocurrir eso que especificas, pero si previamente uno conoce la longitud de algo (nombres, apellidos, telefono, etc) datos alfanumericos, con esto previamente uno puede decidir que tipo de datos utilizar, CHAR solo ocupa 1 byte en memoria por caracter, VARCHAR ocupa 2 bytes por caracter ademas de que este ultimo desfragmenta mucho, TEXT por el otro lado me parece haber leido que es un tipo de dato constante como CHAR (No lo afirmo pero me parece que vi que era asi, lo confirmo manana) Y si esto realmente es asi... eso quiere decir que ya que TEXT soporta 65,400 mas o menos de bytes (cantidad de caracteres maximo en total) y recuerda que TEXT no se le puede indicar hasta que longitud almacenar ya que por defecto el almacena hasta su maxima cantidad (En este caso 65,400 mas o menos) esto quiere decir, que si tu insertas 1 nombre de 20 caracteres.. el te ocupara los bytes restantes (65,380) de ceros (Justo como hace CHAR) que son datos constantes, y si esto realmente es asi, asumo no tendras problemas en que tu datafile crezca masivamente con inserciones simples  (Espero que tengas mucha capacidad de disco duro para este impacto)

Por mas largo que sea un nombre, no superaria los 50 o 60 bytes (nombre no apellido). Me fio de CHAR por ser constante, por no desfragmentarse, y para datas alfanumericas menores que 255 va de lujo. Pero TEXT es un crimen usar TEXT para esos tipos de registros.

No se PHP 

Pero tratando de interpretar tu codigo (si funciona) esto:

Código (sql) [Seleccionar] Expandir


$min=$max-10;
$mensajes=mysql_query('SELECT * FROM mensajes ORDER BY correlativo LIMIT '.$min.','.$max.';');
while($fila=mysql_fetch_array($mensajes)){



Deberia hacer justamente lo que te especifique en el paso 1 de mi ejemplo, que seria seleccionar todos los registros de la tabla (Supongamos que en total tienes 200 registros) los cuales se le asigna el valor a la variable $max y la variable $min = $max-10 por lo cual los datos a mostrar irian reduciendose de 10 en 10 

Aun desconozco si quieres captar la data desde el final de todos los registros o desde el inicio. Pero si utilizas el ORDER BY sin especificarle ascendiente o descendiente, por defecto el utiliza Ascendiente. 

Me avisas cuando pruebes tu codigo.

PD: Se me olvidaba, ten pendiente que los registros dentro de los campos de las tablas son contados por LIMIT como en programacion accesamos a indices de un arreglo. Digase que el primer registro de una tabla se accede a el mediante 0, no comienza en 1 sino en 0

Saludos.

Pasalo todo a una base de datos, ya que la base de datos posee su propio Buffer cache para manipular data y indices(dependiendo el motor de almacenamiento) el cual puedes manipular su tamanio. Ademas de otras ventajas que haran menos forzosas tantas entradas y salidas del disco de un archivo TXT.

Si tu archivo TXT tiene por ejemplo datos de este estilo:

marian, rodriguez
pedro, gomez
mario, perez
juana, mejia
coco, channel
pepe, lopez

Y tu quieres transportar todo a MySQL por ejemplo, sencillamente creas una tabla para acaparar la informacion anterior, que son nombres y apellidos:

CREATE TABLE ejemplo ( nombres CHAR(15), apellidos CHAR(15))

Y luego a importar

Código (sql) [Seleccionar] Expandir



mysql> select * from ejemplo;
Empty set (0.00 sec)

mysql> load data local infile '/home/marian/archivo.txt' into table ejemplo fields terminated by ',';
Query OK, 6 rows affected (0.00 sec)
Records: 6  Deleted: 0  Skipped: 0  Warnings: 0

mysql> select * from ejemplo;
+---------+-----------+
| nombres | apellidos |
+---------+-----------+
| marian  |  sanchez  |
| pedro   |  gomez    |
| mario   |  perez    |
| juana   |  mejia    |
| coco    |  channel  |
| pepe    |  lopez    |
+---------+-----------+
6 rows in set (0.00 sec)



Donde FIELDS TERMINATED BY indica donde vas a especificar que se corte la data para pasar la subsiguiente al proximo campo 

Ademas con una DB y datos pasados, podras crear indices , relacionarlos, etc, etc...

SI mas o menos entiendo tu punto en no querer tener tantos datos relevantes y repetidos cuando haces referencia a una misma cosa exceptuando 1 solo campo en la tabla que uses de relacion.

Tu dices que hay 1 representante por cada pais, y que hay 1 representante por cada provincia de cada pais, y que hay 1 comarca (que no se que es esto) que es el que recibe la informacion top10 por parte del representante de un pais, no sin antes este representante recibir todas las circulares de todos los representantes de cada provincia? Lol eso es lo que entiendo 

Seria algo como:

Tabla_rep_provincia  --> Tabla_rep_pais --> Tabla_Comarca --> Tabla_top10

Seria mas o menos asi la relacion??? o sea la info pasa primero al representante de la provincia, luego pasa al representante de dicho pais, luego pasa al Comarca y finalmente pasa a una tabla top10? 

Sobre tu imagen mostrada, y de antemano puedo decirte una completa ignorancia y mal consejo porque no capto en su totalidad que estas buscando lograr. A simple vista no podria ser las tablas:

web_oracion_pais_t10
web_oracion_cat_10
web_oracion_provincia_t10

Una sola tabla? lo mismo expreso y pregunto para las tablas superiores:

web_oracion_pais
web_oracion_ca
web_oracion_provincia

No podrian ser una sola tabla? digo analizalo sino te afecta las relaciones en algun punto. Hay varias maneras de relacionar entidades, de forma desglosada como la tienes actualmente (Y mas entendible para cualquier DBA futuro) o de manera conjunta (La cual yo utilizo bastante para evitarle al motor tantos recorridos y perdida de tiempo al optimizador interno  )
Pero no te digo que sea lo mas recomendable, a mi me gusta porque me gusta ahorrar trabajo al motor y porque yo de antemano se donde puede o no afectarme una relacion de entidades si mezclo tablas, pero en tu caso me queda un poco lejano porque aun no tengo la idea clara del escenario que compone los datos de tus tablas.

Pero dime si no es posible juntar esas tablas mencionadas anteriormente y porque.