Consulta muuuuuuy difícil: ¿alguien me ayuda?

[kaslimon]

Hola a todos!!,

Tengo que conseguir realizar una consulta en SQL Server bastante dificil y hasta ahora no lo he conseguido.

Objetivo:
Dada una cadena que indica quien va a servir una orden , llamémosla 'clerk', hay que localizar la orden más antigua (a través del campo TimePlaced) de la tabla Orders y actualizar el campo ServedBy con dicha cadena.

Tabla Orders:
OrderId : varchar
....
TimePlaced: datetime
ServedBy : varchar


RESTRICCIÓN MUY IMPORTANTE: Por asuntos de concurrencia es necesario realizar dicha consulta de forma atómica, es decir, usando una única consulta del tipo select .... into

Habrá que usar una tabla auxiliar , llamémosla 'Served', con lo que la cosa queda así:

Tabla Orders:
OrderId : varchar
....
TimePlaced: datetime
ServedBy : varchar

Tabla Served
OrderId: varchar
ServedBy:varchar



OBJETIVO FINAL: Buscar la orden más antigua de la tabla Orders tal que su OrderId no se encuentre en la tabla Served, e insertar dicho OrderId en la tabla Served de forma atómica.


¿Alguien se atreve?


Muchas gracias por adelantado

[Jorge_Mota]

claro, tambien te podemos hacer la tarea de matematicas.

[kaslimon]

No se trata de un ejercicio de clase. Es un problema real que ha surgido al intentar crear un sistema de protocolos de contienda para cuando hay problemas de acceso concurrente a la BD en un sistema de peticiones de compra (POS).

Las restricciones que comento son las conclusiones a las que he llegado y si pido ayuda es pq no conozco bien las carácterísticas concretas de SQL Server, ya que MySql no permite las consultas de tipo SELECT... INTO.

Si alguien quiere prestar ayuda , se lo agradeceré, pero no necesito comentarios absurdos.

[biffly]

hola, lo que podes hacer es crear una vista en SQL para probar la sentencia, pero lo que yo te recomiedo es que tratesde hacerlo usando procedimientos almacenados ya que estos te permiten realizar varias consultas actualizaciones e inserciones al mismo tiempo y mesclarlas a estas con un codigo muy parecido a basic. espero que esto te oriente un poco mas

Saludos :)

[Mithrandir]

Si usas transacciones no tienes por que preocuparte de la concurrencia y lo puedes hacer en cuantas sentencias necestes.

También revisa los TRANSACTION ISOLATION LEVELS para que veas cual te ayuda mejor.

[biffly]

Mithrandir: podrias explicarme de que se trata eso de las transacciones, ya que nunca las use?

gracias

[kaslimon]

Otra de las restricciones es que no se puede usar un Isolation level muy restrictivo puesto que se ralentiza el sistema. Debe hacer con el nivel 1.

Y ademas todo se debe hacer con una única consulta sql desde java con JDBC.
facil, eh?

Muchas gracias por intentar ayudarme!!

[Mithrandir]

biffly, esto es algo de lo que menciona el archivo de ayuda al respecto (mas aparte este otro link):

Isolation Levels
When locking is used as the concurrency control mechanism, it solves concurrency problems. This allows all transactions to run in complete isolation of one another, although there can be more than one transaction running at any time.

Serializability is the database state achieved by running a set of concurrent transactions equivalent to the database state that would be achieved if the set of transactions were executed serially in order.

SQL-92 Isolation Levels
Although serialization is important to transactions to ensure that the data in the database is correct at all times, many transactions do not always require full isolation. For example, several writers are working on different chapters of the same book. New chapters can be submitted to the project at any time. However, after a chapter has been edited, a writer cannot make any changes to the chapter without the editor's approval. This way, the editor can be assured of the accuracy of the book project at any point in time, despite the arrival of new unedited chapters. The editor can see both previously edited chapters and recently submitted chapters.

The level at which a transaction is prepared to accept inconsistent data is termed the isolation level. The isolation level is the degree to which one transaction must be isolated from other transactions. A lower isolation level increases concurrency, but at the expense of data correctness. Conversely, a higher isolation level ensures that data is correct, but can affect concurrency negatively. The isolation level required by an application determines the locking behavior SQL Server uses.

SQL-92 defines the following isolation levels, all of which are supported by SQL Server:

Read uncommitted (the lowest level where transactions are isolated only enough to ensure that physically corrupt data is not read).


Read committed (SQL Server default level).


Repeatable read.


Serializable (the highest level, where transactions are completely isolated from one another).
If transactions are run at an isolation level of serializable, any concurrent overlapping transactions are guaranteed to be serializable.

These isolation levels allow different types of behavior.

Isolation level Dirty read Nonrepeatable read Phantom
Read uncommitted Yes Yes Yes
Read committed No Yes Yes
Repeatable read No No Yes
Serializable No No No


Transactions must be run at an isolation level of repeatable read or higher to prevent lost updates that can occur when two transactions each retrieve the same row, and then later update the row based on the originally retrieved values. If the two transactions update rows using a single UPDATE statement and do not base the update on the previously retrieved values, lost updates cannot occur at the default isolation level of read committed.