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

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 comprobar si puedes aplicar tus conocimientos sobre bases de datos para resolver problemas reales. Buscan experiencia práctica en la 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 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 de almacenamiento físico de los datos en la tabla; piensa en una guía telefónica ordenada por apellidos.
• Los índices no agrupados son como el índice al final de un libro de texto: apuntan a la ubicación de 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 muchos no agrupados. Los índices agrupados son más rápidos para consultas de rango, mientras que los índices no agrupados son mejores para coincidencias exactas en diferentes columnas.

¿Cómo optimizas una consulta lenta?

Empieza analizando 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';

Estas son algunas técnicas de optimización habituales:

• Añade índices en las columnas utilizadas en las cláusulas WHERE, JOIN y ORDER BY.
• Limitar 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 necesitas.

Comprueba si hay exploraciones de tablas en el plan de ejecución, ya que suelen ser los mayores enemigos del rendimiento.

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

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

Niveles de aislamiento controlan cómo las transacciones simultáneas ven los cambios de las demás:

• LEER SIN COMPROMISO: Puede leer cambios no confirmados (posibles lecturas sucias).
• READ COMMITTED: Solo lee datos confirmados (predeterminado en la mayoría de las bases de datos).
• REPEATABLE READ: 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.

• Divisió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 por rangos utiliza rangos de valores como fechas o ID.

Las ventajas 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 mantiene 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, ya que es mucho más rápido porque se 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 presentan algunas estrategias para evitar los bloqueos:

• Acceder a las tablas en el mismo orden en todas las transacciones
• Mantén las transacciones breves
• Utiliza niveles de aislamiento adecuados.
• Implementa una 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í tienes 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 valores vacíos
• : 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 rápidamente, 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 la escritura, varios esclavos se encargan de la lectura. Los cambios fluyen del maestro a los esclavos.
• Replicación maestro-maestro: Varios maestros pueden gestionar escrituras y lecturas. 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 deben utilizarse?

Los desencadenadores de bases de datos son procedimientos especiales que se ejecutan automáticamente en respuesta a eventos de la base 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 desencadenadores son útiles para actualizar automáticamente marcas de tiempo, registrar cambios para registros 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 tu conocimiento profundo de la arquitectura DBMS y las operaciones complejas de bases de datos.

Los entrevistadores utilizan preguntas avanzadas para comprobar 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 fragmentación de bases de datos y sus ventajas e inconvenientes.

La fragmentación de bases de datos divide una base de datos grande horizontalmente en varios servidores, y cada fragmento contiene solo un subconjunto de los datos.

Particionas los datos en función de 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 la escalabilidad horizontal, un mejor rendimiento y el aislamiento de fallos (el fallo de un fragmento no lo inutiliza todo).

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 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 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 : dan prioridad a la disponibilidad y la tolerancia a particiones, al tiempo que logran la consistencia a lo largo del tiempo.

¿Cómo diseñas 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 simultáneas.

Uso 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:

• Partición de tablas activas 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 generen conflictos.
• Diseña para cargas de trabajo que principalmente añaden datos cuando sea posible: las inserciones causan menos conflictos que las actualizaciones.

Explica MVCC (control de concurrencia multiversión).

MVCC permite que varias transacciones accedan a los mismos datos al mismo tiempo sin bloqueos, 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 se garantiza la coherencia de las lecturas dentro de las transacciones.

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

¿Qué son las vistas materializadas y cuándo deben utilizarse?

Las vistas materializadas almacenan el resultado de una consulta físicamente 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 obsolescencia de los datos entre actualizaciones. Funcionan mejor cuando puedes tolerar datos ligeramente desactualizados para obtener un mejor rendimiento de las consultas.

¿Cómo gestionas 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 desde el almacenamiento.

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:

• Optimiza los índices para búsquedas por rango en lugar de acceso aleatorio.
• Utiliza el almacenamiento en columnas para cargas de trabajo analíticas 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 contienda, donde los conflictos son habituales.
• Optimistic funciona mejor para cargas de trabajo con mucho contenido 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 uniones costosas:

-- 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 de evitar las uniones.
• El almacenamiento es más barato que el tiempo de computación.
• Podrás gestionar 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 diseñas para la recuperación ante desastres y la alta disponibilidad?

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

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

• Primaria: Gestiona todas las escrituras
• Réplica 1: Gestiona las consultas leídas en la misma región.
• Réplica 2: Gestiona las consultas leídas 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 determinado
• 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 hayan fallado.
• 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 la agrupación 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 entre redes, 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 la piscina en función del número de usuarios simultáneos y la capacidad de la base de datos: si es demasiado pequeña, 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 que se plantean en el mundo de 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 les hacía abandonar 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 me di cuenta de 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 pruebas, lo implementé durante las horas de poco 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 la medición, las pruebas y los resultados cuantificables.

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

Céntrate en cómo hiciste accesibles los conceptos técnicos a 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 generarse. 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 todos los recibos 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: que el informe se generara en dos minutos en lugar de veinte, para que pudierais obtener información más rápidamente y responder con mayor agilidad a los cambios del mercado».

Demuestra que puedes traducir el trabajo técnico en valor empresarial 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 en 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 estando accesibles para operaciones críticas de solo lectura.
• Comunicación con las partes interesadas: «Notifico inmediatamente al equipo de respuesta ante 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: «Compruebo los registros del sistema, el espacio en disco, el uso de la 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 en espera.
• Actualizaciones periódicas: «Envío actualizaciones 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é vamos a hacer para evitar que vuelva a ocurrir en el futuro».

La clave está en demostrar que puedes mantener la calma bajo presión y seguir comunicándote con claridad.

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

Sigue 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 artículos de pedido y los productos pertenecen a categorías.
• Planificación del rendimiento: «Añado índices en las columnas que se consultan con frecuencia, como el correo electrónico de los usuarios para iniciar sesión, el SKU de los productos para las búsquedas y las fechas de los pedidos para los informes». También considero dividir tablas grandes como Pedidos por fecha."
• Preparación 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. ¿Qué retos tuviste que afrontar?

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 nuestra 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: «He creado un plan de migración detallado con procedimientos de reversión. Llevamos a cabo la migración por etapas: primero, un subconjunto de tablas y, a continuación, fuimos trasladando el resto poco a poco, 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 cambiar por completo.

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

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

• Escucha y comprende « » (El amor es un arma de fuego): «Siempre empiezo por comprender vuestro punto de vista. A menudo, los desacuerdos provienen de prioridades diferentes: vosotros podéis dar prioridad a la comodidad de los programadores, mientras que yo doy prioridad al rendimiento.
• Presentá 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 puntos de referencia 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 programador quería utilizar un enfoque NoSQL para los perfiles de usuario, pero yo te sugerí un diseño relacional. Debatimos las ventajas e inconvenientes, probamos prototipos de ambos enfoques y elegimos la solución que mejor se adaptaba a nuestros requisitos de coherencia y a la experiencia de nuestro equipo.

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

Demuestra tu capacidad para priorizar y cumplir bajo presión.

Prepara el escenario: «Teníamos un informe crítico de 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 las mejoras de rendimiento más importantes. En lugar de optimizarlo 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 dividí la tabla más grande por fecha. Esto redujo el tiempo de ejecución de 60 minutos a 8 minutos.

Termina con comunicación y 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 para la depuración de problemas intermitentes:

• Establecer un sistema de supervisión: «Configuraría la supervisión para capturar métricas de rendimiento cuando se produzca el problema: tiempos de ejecución de consultas, recursos del sistema, conexiones simultáneas».
• Recopila datos: «Yo habilitaría el registro de consultas para ver qué se está ejecutando cuando el rendimiento disminuye». También comprobaría si hay patrones: ¿ocurre en momentos concretos, con determinados usuarios o durante operaciones específicas?
• Formula hipótesis: «Basándome en los datos, formularía hipótesis. Quizás se trate de un trabajo por lotes que se ejecuta cada hora o de un informe concreto que bloquea las tablas.
• Aislamiento y pruebas: «Intentaré 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 se estaba ejecutando una tarea de sincronización de datos semanal al mismo tiempo que nuestra actividad máxima de usuarios, lo que provocaba conflictos de bloqueo.

Describe cómo gestionarías una solicitud de acceso a la base de datos por parte de alguien que no suele trabajar 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 conseguir. A menudo hay una forma mejor de obtener la información que necesitáis sin acceder directamente a la base de datos.

Ofrece 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, crear un panel de control o exportar los datos que necesitan en un archivo CSV».

Si es necesario el acceso, explica que la seguridad sigue siendo una prioridad: Crearía una cuenta de solo lectura con acceso limitado a las tablas que necesitan. También proporcionarí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 realizar 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.

Demuestra 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 descubrieron 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 se pudo haber 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. Para 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 aprobar 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 realizando 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 problemas reales de rendimiento

Aprende a identificar y resolver los cuellos de botella más comunes en el 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 la identificación de exploraciones de tablas, índices que faltan 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

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

Elige escenarios reales, 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 se adaptaría al crecimiento y a los requisitos cambiantes.

Dibuja diagramas de relaciones entre entidades y prepárate para explicar tus decisiones de diseño. Los entrevistadores suelen preguntar «¿por qué elegiste este enfoque en lugar de otros alternativos?». Asegúrate de tener una respuesta preparada.

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

Repasa los conceptos de SQL y NoSQL.

Aunque tu función se centre en las bases de datos relacionales, debes comprender cuándo tiene sentido utilizar NoSQL.

Conoce los conceptos básicos de los almacenes de documentos como MongoDB, los almacenes de clave-valor 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 retos relacionados con bases de datos.

Prepara entre tres y cuatro historias sobre ocasiones en las que optimizaste consultas lentas, diseñaste esquemas, migraste datos o gestionaste interrupciones del servicio de 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 fragmentación 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 mostrar que estás 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 basta: debes conectar 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 sobre la replicación, explica cómo evita costosos tiempos de inactividad.

Practica cómo explicar conceptos complejos de 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