Las 40 preguntas más frecuentes en entrevistas sobre DBMS en 2026

Preguntas de entrevista sobre DBMS para nivel intermedio

Estas preguntas evalúan tu competencia técnica con las herramientas y conceptos de DBMS.

Los entrevistadores utilizan preguntas intermedias para ver si puedes aplicar tus conocimientos sobre bases de datos para resolver problemas reales. Buscan experiencia práctica en optimización de consultas y comprensión del funcionamiento interno de las bases de datos.

Explica los diferentes tipos de índices y cuándo utilizar cada uno de ellos.

• Los índices agrupados reordenan físicamente los datos de la tabla en función de los valores clave; solo puedes tener uno por tabla, ya que los datos solo se pueden ordenar de una forma.
• Los índices no agrupados crean una estructura independiente que apunta a las filas de la tabla sin cambiar el orden físico. Puedes tener varios índices no agrupados en una tabla.
• Los índices compuestos cubren varias columnas y funcionan mejor cuando las consultas filtran esas columnas juntas.
• Los índices únicos garantizan la unicidad y permiten realizar búsquedas rápidas.
• Los índices parciales solo indexan las filas que cumplen determinadas condiciones, lo que ahorra espacio.

¿Cuál es la diferencia entre un índice agrupado y uno no agrupado?

• Los índices agrupados determinan el orden físico de almacenamiento de los datos en la tabla; piensa, por ejemplo, en una guía telefónica ordenada por apellidos.
• Los índices no agrupados son como el índice al final de un libro de texto: señalan dónde se encuentran los datos reales sin cambiar el orden de las páginas del libro.

A continuación se explica cómo crear índices agrupados y no agrupados:

-- Primary key creates clustered index by default
CREATE TABLE employees (
    id INT PRIMARY KEY CLUSTERED,
    name VARCHAR(100),
    email VARCHAR(100)
);

-- Separate index for fast email lookups
CREATE NONCLUSTERED INDEX idx_email ON employees(email);

Una tabla solo puede tener un índice agrupado, pero puede tener muchos índices no agrupados. Los índices agrupados son más rápidos para las consultas de rango, mientras que los índices no agrupados son mejores para las coincidencias exactas en diferentes columnas.

¿Cómo se optimiza una consulta lenta?

Empieza por analizar el plan de ejecución para ver dónde está el cuello de botella.

EXPLAIN SELECT * FROM orders o 
JOIN customers c ON o.customer_id = c.id 
WHERE o.order_date > '2025-07-01';

A continuación se indican algunas técnicas de optimización habituales:

• Añadir índices en las columnas utilizadas en las cláusulas WHERE, JOIN y ORDER BY.
• Limitar los conjuntos de resultados con cláusulas WHERE antes de unir
• Utiliza índices de cobertura que incluyan todas las columnas necesarias para la consulta.
• Reescribe las subconsultas como JOIN cuando sea posible
• Evita SELECT *: solo recupera las columnas que necesites.

Comprueba si hay exploraciones de tablas en el plan de ejecución, ya que suelen ser los factores que más afectan al rendimiento.

¿Qué son las transacciones de bases de datos y los niveles de aislamiento?

Las transacciones de bases de datos agrupan múltiples operaciones en una sola unidad que o bien se ejecuta correctamente en su totalidad o bien falla por completo.

Los niveles de aislamiento controlan cómo las transacciones concurrentes ven los cambios de las demás:

• LEER SIN COMPROMISO: Puede leer cambios no confirmados (posibilidad de lecturas sucias).
• READ COMMITTED: Solo lee datos confirmados (predeterminado en la mayoría de las bases de datos).
• REPETIBLE LECTURA: La misma consulta devuelve los mismos resultados dentro de una transacción.
• SERIALIZABLE: Aislamiento máximo, las transacciones se ejecutan como si fueran secuenciales.

Los niveles de aislamiento más altos evitan más problemas, pero reducen la concurrencia y el rendimiento.

Explica el concepto de partición de bases de datos.

La partición de bases de datos divide las tablas grandes en partes más pequeñas y manejables, al tiempo que las mantiene lógicamente como una sola tabla. Hay cuatro enfoques que debes conocer.

• La partición horizontal divide las filas según criterios como rangos de fechas:

-- Orders table partitioned by year
CREATE TABLE orders_2023 (...);
CREATE TABLE orders_2024 (...);
CREATE TABLE orders_2025 (...);

• Partición vertical divide las columnas: las columnas a las que se accede con frecuencia en una partición y las que se utilizan con poca frecuencia en otra.
• Partición hash distribuye las filas basándose en una función hash.
• La partición de rangos utiliza rangos de valores como fechas o ID.

Entre las ventajas se incluyen consultas más rápidas (solo se consultan las particiones relevantes), un mantenimiento más sencillo y una mejor paralelización.

¿Cuál es la diferencia entre UNION y UNION ALL?

UNION combina los resultados de varias consultas y elimina los duplicados, mientras que UNION ALL combina los resultados pero conserva todas las filas, incluidos los duplicados.

-- UNION removes duplicates (slower)
SELECT name FROM employees WHERE department = 'IT'
UNION
SELECT name FROM employees WHERE salary > 50000;

-- UNION ALL keeps duplicates (faster)
SELECT name FROM employees WHERE department = 'IT'
UNION ALL
SELECT name FROM employees WHERE salary > 50000;

Usa UNION ALL cuando sepas que no habrá duplicados o cuando los duplicados no importen; es mucho más rápido porque omite el paso de deduplicación.

¿Cómo gestionas los bloqueos en una base de datos?

Los bloqueos se producen cuando dos transacciones esperan a que la otra libere recursos, creando una dependencia circular.

La mayoría de las bases de datos detectan automáticamente los bloqueos y eliminan una transacción (la «víctima del bloqueo»), permitiendo que la otra continúe. La transacción cancelada se revierte y devuelve un error.

-- Transaction 1
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- waits for lock on account 2

-- Transaction 2  
BEGIN;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
-- tries to update account 1 -> DEADLOCK

A continuación, se indican algunas estrategias para evitar los bloqueos:

• Acceder a las tablas en el mismo orden en todas las transacciones.
• Mantén las transacciones breves.
• Utiliza los niveles de aislamiento adecuados.
• Implementa la lógica de reintento en tu aplicación.

¿Cuál es el propósito de las restricciones de bases de datos?

Las restricciones de la base de datos aplican las reglas de negocio y mantienen la integridad de los datos a nivel de la base de datos. Aquí hay cinco tipos de restricciones que todo profesional de bases de datos debe conocer:

• Clave principal: Garantiza una identificación única.
• Clave externa: Mantiene la integridad referencial.
• Visita: Valida que los datos cumplen condiciones específicas.
• : no nulo. Evita los valores vacíos.
• único: Garantiza que no haya duplicados.

Así es como funcionan en la práctica:

CREATE TABLE employees (
    id INT PRIMARY KEY,
    email VARCHAR(100) UNIQUE NOT NULL,
    age INT CHECK (age >= 18 AND age <= 65),
    department_id INT,
    FOREIGN KEY (department_id) REFERENCES departments(id)
);

Las restricciones evitan que los datos erróneos entren en tu base de datos y detectan los errores de forma temprana, antes de que se propaguen por tu aplicación.

Explica la replicación de bases de datos y sus tipos.

La replicación de bases de datos copia datos de una base de datos a otras bases de datos para mejorar la disponibilidad, el rendimiento y la recuperación ante desastres.

Hay cuatro tipos de replicación que debes conocer:

• Replicación maestro-esclavo: Un maestro se encarga de las escrituras, varios esclavos se encargan de las lecturas. Los cambios fluyen del maestro a los esclavos.
• Replicación maestro-maestro: Varios maestros pueden gestionar las operaciones de escritura y lectura. Más complejo, pero elimina el punto único de fallo.
• Replicación sincrónica: Espera la confirmación de las réplicas antes de confirmar (más lento pero más consistente).
• Replicación asíncrona: Se confirma inmediatamente y se replica más tarde (más rápido, pero con posible pérdida de datos).

¿Qué son los desencadenadores de bases de datos y cuándo debes utilizarlos?

Los desencadenadores de bases de datos son procedimientos especiales que se ejecutan automáticamente en respuesta a eventos de bases de datos como INSERT, UPDATE o DELETE.

Aquí tienes un ejemplo sencillo:

CREATE TRIGGER update_modified_date
BEFORE UPDATE ON employees
FOR EACH ROW
BEGIN
    SET NEW.modified_at = NOW();
END;

Los desencadenantes son útiles para actualizar automáticamente las marcas de tiempo, registrar cambios para pistas de auditoría, aplicar reglas comerciales complejas o mantener campos calculados.

Sin embargo, los desencadenantes pueden dificultar la depuración, ralentizar las operaciones y crear dependencias ocultas. Úsalos con moderación y documéntalos bien.

Ahora pasemos a las preguntas avanzadas de la entrevista sobre DBMS.

Preguntas avanzadas para entrevistas sobre DBMS

Estas preguntas evalúan tus conocimientos profundos sobre la arquitectura de los sistemas de gestión de bases de datos (DBMS) y las operaciones complejas con bases de datos.

Los entrevistadores utilizan preguntas avanzadas para ver si eres capaz de diseñar y resolver problemas en sistemas de bases de datos a gran escala. Quieren ver si comprendes las ventajas e inconvenientes de los diferentes enfoques y si eres capaz de tomar decisiones informadas sobre la arquitectura de la base de datos.

Explica el fragmentado de bases de datos y sus ventajas e inconvenientes.

El fragmentado de bases de datos divide una base de datos grande horizontalmente entre varios servidores, de modo que cada fragmento contiene solo un subconjunto de los datos.

Particionas los datos basándote en una clave de fragmentación, como el ID de usuario, la ubicación geográfica o el intervalo de fechas. Cada fragmento funciona de forma independiente, lo que te permite escalar más allá de lo que puede manejar un solo servidor.

-- Example: Sharding users by ID ranges
-- Shard 1: user_id 1-1000000
-- Shard 2: user_id 1000001-2000000
-- Shard 3: user_id 2000001-3000000

Entre las ventajas se incluyen el escalado horizontal, un mejor rendimiento y el aislamiento de fallos (el fallo de un fragmento no afecta al conjunto).

Las desventajas incluyen una lógica de aplicación compleja, la imposibilidad de realizar transacciones entre fragmentos, la dificultad para reequilibrar y la pérdida de algunas garantías ACID entre fragmentos. Las consultas que abarcan varios fragmentos resultan costosas.

¿Qué es el teorema CAP y cómo afecta al diseño de bases de datos?

El teorema CAP establece que los sistemas distribuidos solo pueden garantizar dos de las tres propiedades siguientes: Consistencia, disponibilidad y tolerancia a particiones:

• Consistencia: Todos los nodos ven los mismos datos al mismo tiempo.
• Disponibilidad: El sistema sigue funcionando incluso cuando fallan los nodos.
• Tolerancia de partición: El sistema continúa funcionando a pesar de los fallos de red entre los nodos.

Dado que solo dos de tres están garantizados, estas son las combinaciones más comunes:

• Los sistemas CA (como los RDBMS tradicionales) sacrifican la tolerancia a las particiones, ya que no pueden gestionar bien las divisiones de red.
• Los sistemas CP (como MongoDB en determinadas configuraciones) sacrifican la disponibilidad, ya que pueden rechazar solicitudes para mantener la coherencia.
• Los sistemas AP (como Cassandra) sacrifican la consistencia: siguen estando disponibles, pero los datos pueden ser temporalmente inconsistentes entre los nodos.

La mayoría de las bases de datos distribuidas modernas son eventualmente consistentes : priorizan la disponibilidad y la tolerancia a las particiones, al tiempo que logran la consistencia a lo largo del tiempo.

¿Cómo se diseña un esquema de base de datos para una alta concurrencia?

Comienza por reducir la contienda por los bloqueos diseñando tablas que reduzcan los conflictos entre operaciones concurrentes.

Usa bloqueo optimista con columnas de versión en lugar de bloqueos pesimistas:

-- Add version column for optimistic locking
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10,2),
    inventory_count INT,
    version INT DEFAULT 1
);

-- Update with version check
UPDATE products 
SET inventory_count = inventory_count - 1, version = version + 1
WHERE id = 123 AND version = 5;

Otros consejos para diseñar para una alta concurrencia:

• Tablas calientes de partición por tiempo u otros límites lógicos
• Utiliza tablas separadas para diferentes patrones de acceso en lugar de tablas amplias con usos mixtos.
• Evita los índices amplios que crean conflictos.
• Diseño para cargas de trabajo principalmente de adición cuando sea posible: las inserciones causan menos conflictos que las actualizaciones.

Explica qué es MVCC (control de concurrencia multiversión).

MVCC permite que varias transacciones accedan a los mismos datos al mismo tiempo sin bloqueo, manteniendo varias versiones de cada fila.

Cuando inicias una transacción, obtienes una instantánea de la base de datos en ese momento. Otras transacciones pueden modificar los datos, pero tu transacción solo ve la versión que existía cuando la iniciaste.

-- Transaction A starts at time T1
BEGIN; -- Sees version 1 of all data

-- Transaction B modifies data at time T2  
UPDATE accounts SET balance = 1000 WHERE id = 1; -- Creates version 2

-- Transaction A still sees version 1
SELECT balance FROM accounts WHERE id = 1; -- Returns old value

COMMIT; -- Transaction A commits with its snapshot

Entre las ventajas se incluyen el hecho de que los lectores no bloquean a los escritores, los escritores no bloquean a los lectores y las lecturas son coherentes dentro de las transacciones.

Entre los inconvenientes se incluyen los gastos generales de almacenamiento de múltiples versiones y los procesos de limpieza para eliminar las versiones antiguas.

¿Qué son las vistas materializadas y cuándo debes utilizarlas?

Las vistas materializadas almacenan físicamente el resultado de una consulta en el disco, a diferencia de las vistas normales, que ejecutan la consulta cada vez.

Son perfectos para agregaciones costosas que no necesitan datos en tiempo real:

-- Create materialized view for monthly sales summary
CREATE MATERIALIZED VIEW monthly_sales AS
SELECT 
    DATE_TRUNC('month', order_date) as month,
    SUM(total_amount) as total_sales,
    COUNT(*) as order_count
FROM orders 
GROUP BY DATE_TRUNC('month', order_date);

-- Refresh when needed
REFRESH MATERIALIZED VIEW monthly_sales;

Son ideales para consultas en paneles de control, informes y análisis complejos que se ejecutan repetidamente sobre datos estables.

Las desventajas incluyen espacio de almacenamiento adicional, gastos generales de mantenimiento y datos obsoletos entre actualizaciones. Funcionan mejor cuando puedes tolerar datos ligeramente desactualizados para obtener un mejor rendimiento de las consultas.

¿Cómo manejas conjuntos de datos muy grandes que no caben en la memoria?

Diseña operaciones basadas en disco comprendiendo cómo tu base de datos accede a los datos almacenados.

Utiliza la partición para asegurarte de que las consultas solo afecten a los segmentos de datos relevantes:

-- Partition by date so queries can skip irrelevant partitions
CREATE TABLE sales_data (
    sale_date DATE,
    amount DECIMAL(10,2),
    customer_id INT
) PARTITION BY RANGE (sale_date);

Otros consejos para manejar conjuntos de datos más grandes que la memoria:

• Optimizar los índices para búsquedas por rango en lugar de acceso aleatorio.
• Utiliza el almacenamiento en columnas para cargas de trabajo de análisis en las que se agregan columnas específicas.
• Implementar el almacenamiento en caché y la paginación de los resultados de las consultas para las consultas de los usuarios.
• Utiliza réplicas de lectura para distribuir la carga de consultas entre varias máquinas.
• Considera el archivo de datos : traslada los datos antiguos a un almacenamiento más económico y conserva solo los datos recientes en la base de datos principal.

Explica la diferencia entre bloqueo pesimista y optimista.

El bloqueo pesimista asume que se producirán conflictos y bloquea los recursos inmediatamente para evitarlos, mientras que el bloqueo optimista asume que los conflictos son poco frecuentes y solo comprueba si hay conflictos al confirmar los cambios.

-- Pessimistic: Lock the row immediately
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE; -- Locks the row
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

-- Optimistic: Check version before updating
SELECT id, balance, version FROM accounts WHERE id = 1;
-- Application logic happens here
UPDATE accounts 
SET balance = balance - 100, version = version + 1 
WHERE id = 1 AND version = 3; -- Fails if someone else updated it

• El pesimismo funciona mejor en situaciones de alta contención en las que los conflictos son habituales.
• Optimistic funciona mejor para cargas de trabajo con gran volumen de lectura, en las que los conflictos son poco frecuentes.

¿Qué es la desnormalización de bases de datos y cuándo es adecuada?

La desnormalización añade intencionadamente redundancia a las tablas normalizadas para mejorar el rendimiento de las consultas.

Duplicas datos entre tablas para evitar costosas uniones:

-- Normalized: Requires join for order details
SELECT o.id, c.name, c.email 
FROM orders o 
JOIN customers c ON o.customer_id = c.id;

-- Denormalized: Customer info stored in orders table
SELECT id, customer_name, customer_email 
FROM orders_denormalized;

Cuándo desnormalizar:

• El rendimiento de lectura es más importante que el rendimiento de escritura.
• Tienes patrones de consulta predecibles que se benefician al evitar las uniones.
• El almacenamiento es más barato que el tiempo de computación.
• Puedes manejar la complejidad de mantener sincronizados los datos desnormalizados.

Los riesgos incluyen la inconsistencia de los datos, el aumento de los costes de almacenamiento y una lógica de actualización más compleja.

¿Cómo se diseña para la recuperación ante desastres y la alta disponibilidad?

Comienza por diseñar con redundancia en todos los niveles: múltiples servidores de bases de datos, rutas de red y centros de datos.

Configura la replicación con conmutación automática por error:

• Primaria: Gestiona todas las escrituras.
• Réplica 1: Gestiona las consultas de lectura en la misma región.
• Réplica 2: Gestiona consultas de lectura en una región diferente.
• Réplica 3: Preparación para la recuperación ante desastres

Otros consejos:

• Realiza copias de seguridad periódicas con capacidad de recuperación en un momento dado.
• Prueba los procedimientos de conmutación por error con regularidad : un plan de recuperación ante desastres que no funciona bajo presión es inútil.
• Utiliza equilibradores de carga para desviar el tráfico de los servidores que no funcionan
• Supervisa todo : necesitas conocer los problemas antes que tus usuarios.
• Planifica diferentes escenarios de fallo : fallo de un único servidor, interrupción del servicio del centro de datos, desastres regionales y corrupción de datos.

Explica qué es el agrupamiento de conexiones de bases de datos y por qué es importante.

El agrupamiento de conexiones mantiene una caché de conexiones a la base de datos que las aplicaciones pueden reutilizar en lugar de crear nuevas conexiones para cada solicitud.

Crear conexiones con bases de datos es costoso, ya que implica intercambios de datos en red, autenticación y asignación de recursos. Los grupos de conexiones eliminan esta sobrecarga.

Aquí tienes un ejemplo en Python:

# Without pooling: Creates new connection each time
def get_user(user_id):
    conn = create_connection()  # Expensive!
    result = conn.execute("SELECT * FROM users WHERE id = ?", user_id)
    conn.close()
    return result

# With pooling: Reuses existing connections
pool = ConnectionPool(max_connections=20)
def get_user(user_id):
    conn = pool.get_connection()  # Fast!
    result = conn.execute("SELECT * FROM users WHERE id = ?", user_id)
    pool.return_connection(conn)
    return result

Entre las ventajas se incluyen tiempos de respuesta más rápidos, menor carga de la base de datos, uso controlado de los recursos y mejor gestión de los picos de tráfico.

Debes dimensionar el pool en función del número de usuarios simultáneos y la capacidad de la base de datos: si es demasiado pequeño, se producirán esperas, y si es demasiado grande, se desperdiciarán recursos.

Preguntas sobre DBMS basadas en comportamientos y escenarios

Estas preguntas evalúan tus habilidades para resolver problemas y tu experiencia trabajando con clientes y equipos de datos.

Los entrevistadores utilizan preguntas sobre comportamiento y situaciones hipotéticas para ver cómo manejas los retos reales relacionados con las bases de datos. Quieren comprender tu proceso de pensamiento, tus habilidades comunicativas y tu capacidad para trabajar con personas sin conocimientos técnicos cuando surgen problemas con las bases de datos.

Cuéntame alguna ocasión en la que hayas tenido que optimizar una consulta lenta. ¿Cuál fue tu enfoque?

Estructura tu respuesta para mostrar un proceso claro de resolución de problemas.

Comienza describiendo el problema y su impacto: Tu panel de control de clientes tardaba 45 segundos en cargarse porque la consulta principal realizaba un escaneo completo de una tabla con un millón de filas. Esto frustraba a los usuarios y hacía que abandonaran la página».

Explica tu enfoque diagnóstico: Analicé el plan de ejecución de la consulta y descubrí que faltaba un índice en las columnas utilizadas en la cláusula WHERE. También noté que la cláusula ORDER BY no estaba optimizada.

Explica tu solución y resultados: He creado un índice compuesto que abarca tanto las columnas de filtro como las de ordenación. Después de probarlo en nuestro entorno de ensayo, lo implementé durante las horas de menor tráfico. El tiempo de consulta se redujo de 45 segundos a menos de 2 segundos, lo que resolvió el problema de rendimiento del panel de control.

En tu respuesta, haz siempre hincapié en las mediciones, las pruebas y los resultados cuantificables.

Describe una situación en la que tuviste que explicar un concepto complejo relacionado con bases de datos a una parte interesada sin conocimientos técnicos.

Céntrate en cómo hiciste que los conceptos técnicos fueran accesibles para las partes interesadas de la empresa.

Elige un ejemplo concreto en el que hayas logrado salvar la brecha técnica. Podrías decir: Nuestro equipo de marketing estaba frustrado porque el informe de segmentación de clientes tardaba 20 minutos en ejecutarse. En lugar de explicar las uniones e índices de bases de datos, utilicé una analogía sencilla.

Describe tu enfoque de comunicación: Les dije que imaginaran que buscaban clientes que hubieran comprado tanto el producto A como el producto B. El sistema actual era como buscar manualmente en cada recibo de un enorme archivador. Tras la optimización, sería como tener carpetas organizadas por tipo de producto, lo que agilizaría mucho la búsqueda.

Muestra el impacto en el negocio: Me centré en lo que les importaba: el informe se generaría en 2 minutos en lugar de 20, por lo que podrían obtener información más rápidamente y responder a los cambios del mercado con mayor rapidez.

Demuestra que puedes traducir el trabajo técnico en valor comercial sin abrumar a las partes interesadas sin conocimientos técnicos con detalles de implementación.

¿Cómo manejarías una situación en la que la base de datos se cae durante las horas punta?

Demuestra tus habilidades para la gestión de crisis mediante una respuesta estructurada:

• Evaluación inmediata: En primer lugar, determino el alcance: ¿se trata de una interrupción total o algunos servicios siguen funcionando? Compruebo si nuestras réplicas de lectura siguen siendo accesibles para operaciones críticas de solo lectura.
• Comunicación con las partes interesadas: Inmediatamente notifico al equipo de respuesta a incidentes y envío una breve actualización del estado a las unidades de negocio afectadas con un calendario estimado para las actualizaciones, incluso si aún no tengo una solución.
• Proceso de diagnóstico: Reviso los registros del sistema, el espacio en disco, el uso de memoria, la conectividad de red y los registros de errores de la base de datos para identificar la causa raíz. Si se trata de un fallo de hardware, inicio la conmutación por error a nuestro servidor de reserva.
• Actualizaciones periódicas: Envío actualizaciones de estado cada 15-30 minutos para mantener informados a los interesados, incluso si no hay avances. La comunicación es tan importante como solucionar el problema.
• Revisión posterior al incidente: «Tras resolver el problema, documento lo que ha ocurrido, por qué ha ocurrido y qué haremos para evitar que vuelva a ocurrir en el futuro».

La clave es demostrar que puedes mantener la calma bajo presión y, al mismo tiempo, comunicarte con claridad.

Explícame cómo diseñarías un esquema de base de datos para una nueva aplicación de comercio electrónico.

Explica tu enfoque paso a paso:

• Recopilación de requisitos: Empiezo por comprender las necesidades del negocio: qué productos se venden, cómo compran los clientes, qué tipo de informes se necesitan y cuál es el volumen de tráfico previsto.
• Identificación de la entidad: Identifico las entidades principales, como usuarios, productos, pedidos, artículos de pedidos, categorías y pagos. Cada entidad representa un concepto empresarial clave que debe ser objeto de seguimiento.
• Diseño de relaciones: Trazo un mapa de cómo se relacionan estas entidades entre sí. Por ejemplo, los usuarios tienen muchos pedidos, los pedidos contienen muchos productos a través de OrderItems y los productos pertenecen a categorías.
• Planificación del rendimiento: Añado índices en las columnas que se consultarán con frecuencia, como el correo electrónico del usuario para el inicio de sesión, el SKU del producto para las búsquedas y las fechas de los pedidos para la elaboración de informes. También considero dividir grandes tablas como Órdenes por fecha.
• , preparado para el futuro: Diseño el esquema para dar cabida a posibles funciones futuras, como reseñas de productos, promociones y seguimiento del inventario, sin necesidad de realizar una reestructuración importante.

Demuestra que piensas tanto en las necesidades inmediatas como en la escalabilidad a largo plazo desde el principio.

Describe una ocasión en la que tuviste que migrar datos de un sistema de base de datos a otro. ¿A qué retos te enfrentaste?

Céntrate en la planificación, la ejecución y la resolución de problemas.

Empieza por proporcionar contexto: «Migramos de MySQL a PostgreSQL para aprovechar la mejor compatibilidad con JSON y las funciones avanzadas de indexación para vuestra carga de trabajo de análisis».

Enumera los problemas y retos: El mayor reto fue gestionar las diferencias entre los tipos de datos: el comportamiento de las marcas de tiempo de MySQL era diferente al de PostgreSQL. También teníamos procedimientos almacenados que había que reescribir.

Discute tu solución: Creé un plan de migración detallado con procedimientos de reversión. Realizamos la migración por etapas: primero, un subconjunto de tablas y, a continuación, trasladamos gradualmente el resto, manteniendo la coherencia de los datos.

Termina con los resultados de la prueba y la validación: Hemos utilizado sistemas paralelos durante dos semanas, comparando los resultados entre las bases de datos antiguas y nuevas para garantizar la integridad de los datos. También realizamos pruebas de carga del nuevo sistema antes de realizar el cambio completo.

¿Cómo manejas los desacuerdos con los miembros del equipo sobre las decisiones de diseño de la base de datos?

Demuestra tus habilidades de colaboración y resolución de conflictos:

• Escucha y comprende: Siempre empiezo por comprender vuestra perspectiva. A menudo, los desacuerdos provienen de prioridades diferentes: ustedes pueden dar prioridad a la comodidad de los programadores, mientras que yo doy prioridad al rendimiento.
• Presenta argumentos basados en datos: Respaldo mis recomendaciones con ejemplos concretos. Si creo que necesitamos un índice, mostraré los planes de ejecución de consultas y los parámetros de rendimiento.
• Encuentra puntos en común: Normalmente estamos de acuerdo en el objetivo final: aplicaciones rápidas y fiables. El desacuerdo es solo sobre cómo llegar allí.

Aquí tienes un ejemplo: Un desarrollador quería utilizar un enfoque nosql para los perfiles de usuario, pero yo sugerí un diseño relacional. Discutimos las ventajas y desventajas, probamos prototipos de ambos enfoques y elegimos la solución que mejor se adaptaba a vuestros requisitos de coherencia y a la experiencia de vuestro equipo.

Cuéntame alguna ocasión en la que hayas tenido que trabajar con un plazo muy ajustado en un proyecto de base de datos.

Demuestra tu capacidad para establecer prioridades y cumplir con los objetivos bajo presión.

Prepara el escenario: Teníamos un informe crítico para un cliente que debía estar listo para una reunión de la junta directiva en tres días, pero la consulta tardaba más de una hora en ejecutarse.

Menciona cómo priorizaste las tareas: Me centré primero en los mayores avances en rendimiento. En lugar de optimizar todo, identifiqué las dos operaciones más costosas del plan de ejecución de la consulta.

Menciona los beneficios inmediatos: Añadí un índice de cobertura para la consulta principal y particioné la tabla más grande por fecha. Esto redujo el tiempo de ejecución de 60 minutos a 8 minutos.

Termina con la comunicación y los resultados: Mantuve informado al director de producto cada pocas horas para que pudieras gestionar las expectativas con la junta directiva si fuera necesario. Entregamos el informe optimizado dos días antes de lo previsto, y se convirtió en una plantilla para informes similares.

¿Cómo abordarías la resolución de un problema de rendimiento de una base de datos que solo se produce de forma esporádica?

Muestra tu enfoque sistemático de depuración para problemas intermitentes:

• Establecer un sistema de supervisión: Había configurado la supervisión para capturar métricas de rendimiento cuando se produjera el problema: tiempos de ejecución de consultas, recursos del sistema, conexiones simultáneas.
• Recopilar datos: Activarías el registro de consultas para ver qué se está ejecutando cuando el rendimiento se degrada. También comprobaría si hay patrones: ¿ocurre en momentos concretos, con determinados usuarios o durante operaciones específicas?
• Formular hipótesis: Basándome en los datos, formularía hipótesis. Quizás sea un trabajo por lotes que se ejecuta cada hora o un informe concreto que bloquea las tablas.
• Aislamiento y pruebas: Intentaría reproducir el problema en un entorno de prueba con volúmenes de datos y patrones de consulta similares.

Aquí tienes un ejemplo: Una vez localicé un problema de rendimiento que solo se producía los martes por la mañana. Resultó que una tarea de sincronización de datos semanal se estaba ejecutando al mismo tiempo que la actividad máxima de los usuarios, lo que provocaba conflictos de bloqueo.

Describe cómo manejarías una solicitud de acceso a la base de datos por parte de alguien que normalmente no trabaja con bases de datos.

Demuestra tu conciencia sobre la seguridad y tu capacidad para enseñar.

Evalúa las necesidades: Primero entendería lo que intentan lograr. A menudo hay una forma mejor de obtener la información que necesitáis sin acceder directamente a la base de datos.

Ofrecer alternativas para mostrar las preocupaciones en materia de seguridad: En lugar de acceder a la base de datos, podría crear una vista de solo lectura, diseñar un panel de control o exportar los datos que necesitas en un archivo CSV.

Si el acceso es necesario, explica que la seguridad sigue siendo una prioridad: Crearía una cuenta de solo lectura con acceso limitado únicamente a las tablas que necesiten. También ofrecería formación básica sobre las mejores prácticas de SQL y qué consultas podrían afectar al rendimiento.

Establece expectativas: Les explicaría por qué es importante no ejecutar consultas costosas durante las horas punta y les pediría que consultaran conmigo antes de ejecutar cualquier operación compleja.

Explícame cómo investigarías los informes de inconsistencia de datos en una base de datos de producción.

Muestra tu enfoque sistemático ante los problemas de integridad de los datos:

• Evaluación inicial: En primer lugar, recopilaría ejemplos concretos de la incoherencia. ¿Qué datos son incorrectos, cuándo se descubrió y cuáles deberían ser?
• Reconstrucción cronológica: Revisaría los registros de la base de datos, los registros de la aplicación y las implementaciones recientes para comprender cuándo pudo haberse introducido la inconsistencia.
• Evaluación del alcance: Realizaría consultas para determinar el alcance del problema. ¿Afecta a todos los registros o solo a algunos específicos? ¿Existen patrones basados en el tiempo, las acciones de los usuarios o las fuentes de datos?
• Análisis de la causa raíz: Buscaría las posibles causas: errores en la aplicación, transacciones fallidas, problemas con la importación de datos o problemas de acceso simultáneo.
• Contención inmediata: Si el problema persiste, identificaría y detendría el proceso que lo causa. En cuanto a los datos históricos, determinaría si la corrección es posible y segura.

Aquí tienes un ejemplo: Una vez encontré pedidos de clientes con cantidades negativas. Al revisar los registros de la aplicación, descubrí una condición de carrera en el proceso de actualización del inventario. Hemos solucionado el error de la aplicación y corregido los pedidos afectados utilizando los registros de transacciones.

Consejos para prepararse para una entrevista sobre DBMS

La mejor manera de superar con éxito una entrevista sobre DBMS es practicar con bases de datos reales, no solo memorizar la teoría. Los entrevistadores quieren ver que puedes resolver problemas reales, no solo recitar definiciones.

Practica SQL con conjuntos de datos reales.

No te limites a practicar con sentencias básicas de « SELECT »: trabaja con datos reales y desordenados.

Descarga conjuntos de datos de Kaggle o utiliza bases de datos públicas como la base de datos de muestra Sakila para MySQL. Practica consultas complejas que impliquen múltiples uniones, subconsultas y agregaciones. El objetivo es que te sientas cómodo con situaciones que realmente te encontrarás en el trabajo.

Las consultas como esta deberían resultar fáciles y no deberías tener ningún problema para explicar ninguna de sus partes:

SELECT 
    c.customer_id,
    c.first_name,
    c.last_name,
    COUNT(r.rental_id) as total_rentals,
    SUM(p.amount) as total_spent
FROM customer c
LEFT JOIN rental r ON c.customer_id = r.customer_id
LEFT JOIN payment p ON r.rental_id = p.rental_id
WHERE r.rental_date >= '2025-07-01'
GROUP BY c.customer_id, c.first_name, c.last_name
HAVING COUNT(r.rental_id) > 10
ORDER BY total_spent DESC;

Configura tu propio entorno de base de datos

Instala un sistema de base de datos localmente y aprende cómo funciona realmente.

Elige uno de los principales sistemas (PostgreSQL, MySQL o SQL Server) y configura una instancia local. Crea tablas, inserta datos y experimenta con diferentes configuraciones. Aprende a leer planes de ejecución, crear índices y supervisar el rendimiento.

Esta experiencia práctica te ayudará a responder preguntas sobre la administración de bases de datos, no solo sobre la sintaxis SQL.

Si estás haciendo una entrevista para un puesto de administrador de bases de datos, debes saber la respuesta a estas 30 preguntas más frecuentes en entrevistas para DBA.

Estudia los problemas reales de rendimiento.

Aprende a identificar y resolver los cuellos de botella más comunes que afectan al rendimiento.

Utiliza herramientas como EXPLAIN o EXPLAIN ANALYZE para comprender cómo se ejecutan tus consultas:

EXPLAIN ANALYZE 
SELECT * FROM orders 
WHERE customer_id = 12345 
AND order_date > '2023-01-01';

Practica identificando escaneos de tablas, índices faltantes y uniones ineficientes. Crea grandes conjuntos de datos y observa cómo las diferentes estrategias afectan al rendimiento de las consultas.

Comprender los planes de ejecución es lo que diferencia a los programadores junior de los senior en las entrevistas.

Practica el diseño de bases de datos.

Trabaja en ejercicios completos de diseño de esquemas, no solo en tablas individuales.

Elige escenarios del mundo real, como un sitio de comercio electrónico, una plataforma de redes sociales o un sistema de inventario. Diseña todo el esquema de la base de datos, incluyendo relaciones, restricciones e índices. Piensa en cómo el diseño gestionaría el crecimiento y los requisitos cambiantes.

Dibuja diagramas de entidad-relación y prepárate para explicar tus decisiones de diseño. Los entrevistadores suelen preguntar «¿por qué elegiste este enfoque en lugar de otras alternativas?». Asegúrate de tener una respuesta preparada.

Te recomiendo que eches un vistazo al curso de Diseño de bases de datos para llevar tus conocimientos al siguiente nivel. 

Revisa los conceptos de SQL y nosql.

Aunque el puesto se centre en bases de datos relacionales, es importante comprender cuándo tiene sentido utilizar nosql.

Conoce los conceptos básicos de los almacenes de documentos como MongoDB, los almacenes de claves-valores como Redis y las bases de datos de familias de columnas como Cassandra. Comprender las ventajas e inconvenientes entre la coherencia y la disponibilidad en los sistemas distribuidos.

Esto demuestra que puedes pensar más allá de una sola tecnología y elegir la herramienta adecuada para cada problema.

El curso «Conceptos NOSQL » es un excelente punto de partida.

Prepara historias sobre problemas reales relacionados con bases de datos.

Piensa en ejemplos concretos en los que hayas resuelto problemas relacionados con bases de datos.

Prepara 3 o 4 historias sobre ocasiones en las que optimizaste consultas lentas, diseñaste esquemas, migraste datos o gestionaste interrupciones en la base de datos. Utiliza el método STAR (Situación, Tarea, Acción, Resultado) para estructurar tus respuestas.

Practica explicando conceptos técnicos a personas sin conocimientos técnicos. Los entrevistadores suelen preguntar cómo comunicarías los problemas relacionados con las bases de datos a las partes interesadas de la empresa.

Mantente al día de las tendencias en bases de datos.

Lee sobre las tecnologías y prácticas modernas de bases de datos.

Sigue blogs sobre bases de datos, asiste a seminarios web o únete a comunidades relacionadas con bases de datos. Conoce temas como el fragmentado de bases de datos, MVCC, bases de datos distribuidas y servicios de bases de datos en la nube.

No es necesario que seas un experto en todo, pero mostrarte al tanto de las tendencias actuales demuestra que te mantienes involucrado en el campo.

Resumen de preguntas de entrevista sobre DBMS

Las entrevistas sobre DBMS evalúan todo, desde la sintaxis básica de SQL hasta decisiones complejas de diseño de sistemas.

Para dominarlos, aprende conceptos básicos como la normalización, la indexación y las transacciones. A continuación, aborda temas avanzados como el fragmentado y el diseño de alta disponibilidad. La teoría por sí sola no es suficiente: debes relacionar los conocimientos sobre bases de datos con problemas empresariales reales.

Los mejores candidatos relacionan los conceptos técnicos con los resultados prácticos. Cuando expliques los índices, menciona cómo reducen el tiempo de consulta de minutos a segundos. Cuando hables de la replicación, explica cómo evita costosos tiempos de inactividad.

Practica cómo explicar conceptos complejos relacionados con bases de datos de forma clara a personas sin conocimientos técnicos. Prepara historias específicas sobre optimización del rendimiento, gestión de interrupciones o diseño de esquemas con resultados medibles: «reducción del tiempo de consulta en un 90 %» es mejor que «consultas más rápidas».

Además de SQL y DBMS, no está de más prepararse para las preguntas de la entrevista sobre almacenes de datos.

Domina los conceptos básicos, practica con datos reales y relaciona siempre tus conocimientos técnicos con el valor empresarial: así es como se triunfa en las entrevistas sobre DBMS. La práctica hace al maestro.

Para aprender las habilidades fundamentales sobre bases de datos y diseño de bases de datos, recomiendo estos cursos y materiales de DataCamp:

• Introducción a las bases de datos relacionales en SQL
• Introducción a Oracle SQL
• SQL Server para administradores de bases de datos
• Introducción a dbt