¿Cómo diseñar una base de datos para almacenar una lista ordenada?

Estoy buscando almacenar una lista ordenada dentro de una base de datos. Quiero realizar las siguientes operaciones de manera eficiente.

1. Insertar (x): inserte el registro x en la tabla
2. Eliminar (x): eliminar el registro x de la tabla
3. Before (x, n): devuelve los registros 'n' que preceden al registro x en la lista ordenada.
4. After (x, n): devuelve los registros 'n' que suceden al registro x en la lista ordenada.
5. Primero (n): devuelve los primeros registros 'n' de la lista ordenada.
6. Último (n): devuelve los últimos registros 'n' de la lista ordenada.
7. Compare (x, y): dados dos registros x e y de la tabla, encuentre si x> y.

El método simple que se me ocurre es almacenar algún tipo de atributo de 'rango' en la tabla y consultar ordenando ese atributo. Pero en este método, insertar / modificar un registro con un rango se convierte en una operación costosa. hay algun metodo mejor?

Específicamente, estoy buscando implementar la tabla usando SimpleDB de Amazon. Pero una respuesta general para una base de datos relacional también debería ser útil.

Actualización en el perfil de carga:

Como estoy planeando esto para una aplicación web, depende de la cantidad de usuarios que usen la aplicación.

Si hay 100k usuarios activos (súper optimismo: P), entonces mi estimación aproximada por día sería

500k selecciona, 100k inserta y elimina, 500k actualizaciones

Esperaría que la mesa crezca hasta 500k en total.

Estoy buscando optimizar las actualizaciones, la inserción y las operaciones de comparación. El rango de los elementos cambiará constantemente y necesito mantener la tabla actualizada.

Si el rango no es completamente arbitrario, sino que se puede derivar de alguna otra propiedad (por ejemplo, nombre, puntaje del jugador, etc.), eche un vistazo a la respuesta de Joel .

Si es una propiedad arbitraria de sus datos, debe almacenarse como una columna en su tabla de registros. Suponiendo que el SimpleDB de Amazon es similar al RDBMS típico, puede indexar esta columna y satisfacer rápidamente todas sus consultas anteriores con la estrategia de indexación adecuada. Esto es normal para un RDBMS.

Dado que espera una alta actividad de inserción y actualización, pero también una actividad de lectura relativamente alta, le recomiendo hacer lo siguiente:

• Agrupe la tabla en el rango, especialmente si la gran mayoría de sus consultas están en contra del rango. Si no es así, o si la elección de una clave de agrupación no está disponible en SimpleDB, simplemente cree un índice con la clasificación como la columna inicial. Esto satisfaría las consultas 3-6.
• Un índice en el registro primero y luego en el rango (o, en el mundo de SQL Server, solo registre y INCLUDEclasifique el rango, o simplemente registre si se ha agrupado en el rango) satisfaría la consulta 7.
• Las operaciones 1 y 2 se pueden optimizar espaciando sus datos adecuadamente (es decir, configurando FILLFACTORen SQL Server). Esto es especialmente importante si se agrupa en rango.
• A medida que inserte o actualice rangos, mantenga la mayor brecha posible entre los números de rango para minimizar la posibilidad de que necesite volver a clasificar un registro existente para acomodar un rango de inserción o actualización. Por ejemplo, si clasifica sus registros en pasos de 1000, deja suficiente espacio para aproximadamente la mitad de esos cambios e inserciones con una probabilidad mínima de que necesite volver a clasificar un registro que no esté directamente involucrado en esos cambios.
• Todas las noches re-clasifica todos los registros para restablecer las brechas de rango entre ellos.
• Puede ajustar la frecuencia de las re-clasificaciones masivas, así como el tamaño de la brecha de rango para acomodar su número esperado de inserciones o actualizaciones en relación con el número de registros existentes. Entonces, si tiene 100K registros y espera que sus inserciones y actualizaciones sean el 10% de eso, deje suficiente espacio para 10K nuevos rangos y vuelva a clasificar por las noches.
• Re-clasificar los registros de 500K es una operación costosa, pero una vez al día o una semana fuera de horario debería estar bien para una base de datos como esa. Esta re-clasificación masiva fuera del horario laboral para mantener las brechas de rango es lo que le ahorra tener que volver a clasificar muchos registros para cada actualización de rango o insertar durante sus horas normales y pico.

Si espera lecturas de 100K + en una tabla de tamaño de 100K +, no recomiendo usar el enfoque de lista vinculada. No escalará bien a esos tamaños.

Generalmente uso el método de "rango" que usted describe. En lugar de perder el tiempo con la actualización de filas cuando los elementos debían reordenarse, a menudo he podido eliminar todos los registros de la lista y volver a insertar nuevos elementos en el orden correcto. Este método está claramente optimizado para su recuperación.

Un enfoque alternativo sería modelar los registros como una lista vinculada mediante el uso de una columna de clave externa reflexiva "predecesora" en la tabla:

ID   setID   item       predecessor
---  ------  ------     ------------
1    1       Apple      null
2    1       Orange     1
3    2       Cucumber   null
4    1       Pear       2
5    1       Grape      4
6    2       Carrot     3

Puede recuperar fácilmente una lista y agregar y quitar elementos con poca sobrecarga, pero sacar los registros en el orden correcto será complicado. Quizás haya una manera inteligente de hacerlo en una sola consulta, probablemente con muchas uniones de tabla con alias.

Utilizo este último enfoque a menudo cuando estoy modelando una relación de estilo de árbol (categorías, carpetas, conjuntos y subconjuntos). En general, he tenido una función recursiva de algún tipo para reconstruir el árbol completo en mi aplicación.

Creo que lo que hay que hacer es almacenar la propiedad o propiedades que se utilizan para calcular el rango y luego construir un índice sobre ellas. En lugar de intentar forzar a la base de datos a almacenar físicamente los datos en orden de clasificación o usar una lista vinculada administrada manualmente, ¿por qué no dejar que el motor de la base de datos haga lo que fue diseñado para hacer?

Estas son las limitaciones de un no RDBMS como simpleDB. Las características que necesita no se pueden implementar en el lado de DB en simpleDB, deben implementarse desde el lado de la programación / aplicación.

Para un RDBMS como SQL server, las características que necesita son rudimentarias para el índice agrupado.

• Insertar (x): inserte el registro x en la tabla> Insertar simple.
• Eliminar (x): eliminar el registro x de la tabla> Eliminar simple.

• Before (x, n): devuelve los registros 'n' que preceden al registro x en la lista ordenada. > Seleccione los mejores resultados n donde x menos que el valor y ordene por cláusula.

• After (x, n): devuelve los registros 'n' que suceden al registro x en la lista ordenada. > Seleccione n resultados superiores donde x sea mayor que el valor y ordene por cláusula.

• Primero (n): devuelve los primeros registros 'n' de la lista ordenada. > Seleccione los mejores n resultados.

• Último (n): devuelve los últimos registros 'n' de la lista ordenada. > Seleccione los mejores resultados después de ordenar por desc.

• Compare (x, y): dados dos registros x e y de la tabla, encuentre si x> y. > Declaración TSQL IF.

Esto es lo que solía volver a clasificar mi tabla de Postgres después de cada inserción:

CREATE OR REPLACE FUNCTION re_rank_list() RETURNS trigger AS $re_rank_list$
DECLARE
    temprow record;
    row_idx integer := 1;    
BEGIN
    FOR temprow IN
    SELECT * FROM your_schema.your_list WHERE list_id = NEW.list_id ORDER BY rank ASC
    LOOP
        UPDATE your_schema.your_list SET rank = row_idx * 100 WHERE id = temprow.id;
        row_idx := row_idx + 1;
    END LOOP;
    RETURN NEW;
END;
$re_rank_list$ LANGUAGE plpgsql;


CREATE TRIGGER re_rank_list AFTER UPDATE ON your_schema.your_list_value
    FOR EACH ROW 
    WHEN (pg_trigger_depth() = 0)
    EXECUTE PROCEDURE re_rank_list();

Para mi caso de uso, el rendimiento no es una preocupación, pero la confianza de que nunca se romperá o actuará de manera extraña es importante.