-
Notifications
You must be signed in to change notification settings - Fork 13
/
Copy pathBases-de-datos.txt
762 lines (556 loc) · 29.6 KB
/
Bases-de-datos.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
===========================
Guía de Base de Datos by dM
===========================
===================
Tipos de relaciones
===================
1 a 1
=====
Aparece cuando un registro de la tabla A sólo puede relacionarse con 1 registro
de la tabla B. Este modelo aparece en relaciones de tipo exclusivo, como por
ejemplo Países-Banderas, ya que cada país tiene una única bandera oficial, y
cada bandera sólo puede pertenecer a un país; otro ejemplo sería Matrículas de
coches y Coche.
1 a varios o 1 a muchos
=======================
En este caso, un registro de la tabla A puede relacionarse con varios de la
tabla B. Es el tipo más habitual y utilizado, y existen numerosos casos; por
ejemplo, domicilios con personas que viven en el mismo, nombre de empresa con
sus trabajadores, proveedores con productos que sirven…
Varios a varios o muchos a muchos
=================================
Se da si varios registros de A pueden relacionarse con varios de B y viceversa.
Es quizás la menos habitual de manera formal.
El ejemplo clásico, es tener dos tablas, una de actores y otra de películas, ya
que lo habitual es que cada actor haya trabajado en varias películas, y que
éstas estén formadas por varios actores.
Fuentes
=======
-https://www.luciamonterorodriguez.com/tipos-de-relaciones-en-bases-de-datos/
====
ACID
====
En bases de datos se denomina ACID a las características de los parámetros que
permiten clasificar las transacciones de los sistemas de gestión de bases de
datos. Cuando se dice que una acción es ACID compliant se indica -en diversos
grados- que ésta permite realizar transacciones.
En concreto, ACID es un acrónimo en inglés de Atomicity, Consistency, Isolation
and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad, en español.
Definiciones
============
-Atomicidad: Si cuando una operación consiste en una serie de pasos, de los que
o bien se ejecutan todos o ninguno, es decir, las transacciones son completas.
-Consistencia: (Integridad). Es la propiedad que asegura que sólo se empieza
aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que
no van a romper las reglas y directrices de Integridad de la base de datos. La
propiedad de consistencia sostiene que cualquier transacción llevará a la base
de datos desde un estado válido a otro también válido. "La Integridad de la Base
de Datos nos permite asegurar que los datos son exactos y consistentes, es decir
que estén siempre intactos, sean siempre los esperados y que de ninguna manera
cambian ni se deformen. De esta manera podemos garantizar que la información que
se presenta al usuario será siempre la misma."
-Aislamiento: Esta propiedad asegura que una operación no puede afectar a otras.
Esto asegura que la realización de dos transacciones sobre la misma información
sean independientes y no generen ningún tipo de error. Esta propiedad define
cómo y cuándo los cambios producidos por una operación se hacen visibles para
las demás operaciones concurrentes. El aislamiento puede alcanzarse en distintos
niveles, siendo el parámetro esencial a la hora de seleccionar SGBDs.
-Durabilidad: (Persistencia). Esta propiedad asegura que una vez realizada la
operación, esta persistirá y no se podrá deshacer aunque falle el sistema y que
de esta forma los datos sobrevivan de alguna manera.
Cumpliendo estos 4 requisitos un sistema gestor de bases de datos puede ser
considerado ACID Compliant.
Fuentes
=======
-https://es.wikipedia.org/wiki/ACID
===
SQL
===
SQL (por sus siglas en inglés Structured Query Language; en español lenguaje de
consulta estructurada) es un lenguaje de dominio específico utilizado en
programación, diseñado para administrar, y recuperar información de sistemas de
gestión de bases de datos relacionales. Una de sus principales características
es el manejo del álgebra y el cálculo relacional para efectuar consultas con el
fin de recuperar, de forma sencilla, información de bases de datos, así como
realizar cambios en ellas.
Originalmente basado en el álgebra relacional y en el cálculo relacional, SQL
consiste en un lenguaje de definición de datos, un lenguaje de manipulación de
datos y un lenguaje de control de datos. El alcance de SQL incluye la inserción
de datos, consultas, actualizaciones y borrado, la creación y modificación de
esquemas y el control de acceso a los datos. También el SQL a veces se describe
como un lenguaje declarativo, también incluye elementos procesales.
===============================
Normalización de bases de datos
===============================
La normalización de bases de datos es un proceso que consiste en designar y
aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo
entidad-relación al modelo relacional. Con objeto de minimizar la redundancia de
datos, facilitando su gestión posterior.
Objetivo
========
Las bases de datos relacionales se normalizan para:
-Minimizar la redundancia de los datos.
-Disminuir problemas de actualización de los datos en las tablas.
-Proteger la integridad de datos.
En el modelo relacional es frecuente llamar tabla a una relación; para que una
tabla sea considerada como una relación tiene que cumplir con algunas
restricciones:
-Cada tabla debe tener su nombre único.
-No puede haber dos filas iguales. No se permiten los duplicados.
-Todos los datos en una columna deben ser del mismo tipo.
Claves
======
Una clave primaria es el conjunto mínimo de columnas que identifica unívocamente
a cada fila. La clave primaria es un identificador que va a ser siempre único
para cada fila. Se acostumbra a poner la clave primaria como la primera columna
de la tabla pero es más una conveniencia que una obligación. Muchas veces la
clave primaria es numérica auto-incrementada, es decir, generada mediante una
secuencia numérica incrementada automáticamente cada vez que se inserta una
fila.
En una tabla puede que tengamos más de una columna que puede ser clave primaria
por sí misma. En ese caso se puede escoger una para ser la clave primaria y las
demás claves serán claves candidatas.
Una clave ajena (foreign key o clave foránea) es aquella columna que existiendo
como dependiente en una tabla, es a su vez clave primaria en otra tabla.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada
como clave primaria, pero que también puede identificar de forma única a una
fila dentro de una tabla. Ejemplo: Si en una tabla clientes definimos el número
de documento (id_cliente) como clave primaria, el número de seguro social de ese
cliente podría ser una clave alternativa. En este caso no se usó como clave
primaria porque es posible que no se conozca ese dato en todos los clientes.
Una clave compuesta es una clave que está compuesta por más de una columna.
La visualización de todas las posibles claves candidatas en una tabla ayudan a
su optimización. Por ejemplo, en una tabla PERSONA podemos identificar como
claves su DNI, o el conjunto de su nombre, apellidos, fecha de nacimiento y
dirección. Podemos usar cualquiera de las dos opciones o incluso todas a la vez
como clave primaria, pero es mejor en la mayoría de sistemas la elección del
menor número de columnas como clave primaria.
=====
NoSQL
=====
En informática, NoSQL (a veces llamado "no solo SQL") es una amplia clase de
sistemas de gestión de bases de datos que difieren del modelo clásico de SGBDR
(Sistema de Gestión de Bases de Datos Relacionales) en aspectos importantes,
siendo el más destacado que no usan SQL como lenguaje principal de consultas.
Los datos almacenados no requieren estructuras fijas como tablas, normalmente no
soportan operaciones JOIN, ni garantizan completamente ACID (atomicidad,
consistencia, aislamiento y durabilidad) y habitualmente escalan bien
horizontalmente.
Los sistemas NoSQL se denominan a veces "no solo SQL" para subrayar el hecho de
que también pueden soportar lenguajes de consulta de tipo SQL.
Por lo general, los investigadores académicos se refieren a este tipo de bases
de datos como almacenamiento estructurado, término que abarca también las bases
de datos relacionales clásicas. A menudo, las bases de datos NoSQL se clasifican
según su forma de almacenar los datos, y comprenden categorías como clave-valor,
las implementaciones de BigTable, bases de datos documentales, y bases de datos
orientadas a grafos.
Los sistemas de bases de datos NoSQL crecieron con las principales redes
sociales, como Google, Amazon, Twitter y Facebook. Estas tenían que enfrentarse
a desafíos con el tratamiento de datos que las tradicionales SGBDR no
solucionaban. Con el crecimiento de la web en tiempo real existía una necesidad
de proporcionar información procesada a partir de grandes volúmenes de datos que
tenían unas estructuras horizontales más o menos similares. Estas compañías se
dieron cuenta de que el rendimiento y sus propiedades de tiempo real eran más
importantes que la coherencia, en la que las bases de datos relacionales
tradicionales dedicaban una gran cantidad de tiempo de proceso.
En ese sentido, a menudo, las bases de datos NoSQL están altamente optimizadas
para las operaciones recuperar y agregar, y normalmente no ofrecen mucho más que
la funcionalidad de almacenar los registros (p.ej. almacenamiento clave-valor).
La pérdida de flexibilidad en tiempo de ejecución, comparado con los sistemas
SQL clásicos, se ve compensada por ganancias significativas en escalabilidad y
rendimiento cuando se trata con ciertos modelos de datos.
Ventajas
========
-Estos sistemas responden a las necesidades de escalabilidad horizontal que
tienen cada vez más empresas.
-Pueden manejar enormes cantidades de datos.
-No generan cuellos de botella.
-Escalamiento sencillo.
-Diferentes DBs NoSQL para diferentes proyectos.
Desventajas
===========
-Limitaciones de Inteligencia de Negocios: Hay una o dos cuestiones acerca de
las capacidades de BI de las bases de datos NoSQL. ¿Pueden estas bases de datos
proporcionar la clase de minería de datos rigurosos que las empresas se utilizan
con las SGBDRes? ¿Cuántos conocimientos de programación se necesitan para hacer
la consulta ad hoc y análisis?. Las respuestas no son precisamente positivas.
Las bases de datos NoSQL no tienen muchos ganchos para el uso general de
herramientas de BI, mientras que la más simple consulta ad-hoc y análisis
implica conocimientos de programación bastante buenos. Sin embargo, las
soluciones están disponibles. Quest Software, por ejemplo, ha creado Toad para
bases de datos en la nube, que proporciona capacidades de consulta ad-hoc para
algunas bases de datos NoSQL.
-La falta de experiencia. La novedad de NoSQL significa que no hay una gran
cantidad de desarrolladores y administradores que conocen la tecnología -lo que
hace difícil a las empresas encontrar personas con los conocimientos técnicos
apropiados. Por el contrario, el mundo SGBDR tiene miles de personas muy
cualificadas.
-Problemas de compatibilidad. A diferencia de las bases de datos relacionales,
que comparten ciertos estándares, las bases de datos NoSQL tienen pocas normas
en común. Cada base de datos NoSQL tiene su propia API, las interfaces de
consultas son únicas y tienen peculiaridades. Esta falta de normas significa que
es imposible cambiar simplemente de un proveedor a otro, por si no quedara
satisfecho con el servicio.
======================================
Marcas y tipos de Bases de Datos NoSQL
======================================
Existe una amplia variedad de Bases de Datos NoSQL que podemos utilizar e
implementar en nuestros proyectos. Todas ellas cumplen funciones especiales con
un excelente rendimiento. Pero debemos analizar nuestros requerimientos y
necesidades para saber escoger cual tomaremos en cuenta para nuestro proyecto.
Conozcamos algunas de las BBDD NoSQL más reconocidas en la actualidad:
MongoDB
=======
Desde las Bases de datos documentales una de las favorita de los desarrolladores
en MongoDB de 10Gen. Sus inicios se remontan a finales de 2007, pero su
liberación en licencia opensource fue en el año 2009. Este importante gestor de
datos NoSQL almacena documentos en un formato muy parecido al JSON a alta
velocidad.
Construido en C++ tiene un rendimiento increíble que le permite ser muy flexible
y potente. Es ideal para proyectos en los que se requiera alto nivel de
escalabilidad. Tiene capacidad para recibir miles de lecturas por segundo sin
pestañear. Múltiples gestores de contenido y juegos online se benefician de sus
propiedades.
Apache Cassandra
================
ApacheCassandra nace desde como un proyecto de google. Varios procesos han
transcurrido desde esa época, hasta que en 2010 obtuvo su graduación como
proyecto de alto nivel en ApacheIncubator.
Es una base de datos de tipo clave-valor. Cassandra es una BBDD NoSQL, está
diseñada para almacenar cantidades gigantescas de datos y realizar
distribuciones a través de varios nodos. Esto permite que el almacenamiento de
datos pueda estar repartido entre diversos servidores sin un solo punto de
fallo. La gran mayoría de nosotros tiene una cercanía con esta base de datos ya
que es una de las herramientas esenciales de Facebook.
Redis
=====
Otro importante motor de base de datos de tipo calve-valor es Redis. Esta BBDD
NoSQL de Código abierto es patrocinada y desarrollada por RedisLabs. Su diseño
principal está basado en el almacenamiento de tablas de hashes aunque no es
restrictiva sólo hacia este modelo. También tiene la posibilidad de ser
utilizada como una BBDD persistente.
Tipos de Bases de Datos NoSQL
=============================
Ya conocimos algunos nombres famosos de las Bases de Datos NoSQL, pero es
importante destacar que existe una clasificación que debemos conocer para
entender cómo estas BBDD están construidas y nos pueden ser de utilidad. Veamos
cuales son las principales clasificaciones:
Bases de datos documentales
===========================
Una base de datos documental u orientada a documentos, es un tipo de BBDD NoSQL
que orienta su funcionamiento a datos alojados en documentos o tiendas de
documentos. Estas bases de datos se utilizan para almacenar, recuperar y
administrar datos semiestructurados.
Las bases de datos documentales almacenan cada uno de los registros y los datos
asociados en un solo documento. Cada documento contiene datos semiestructurados
que pueden ser consultados con diferentes herramientas de análisis. Estas bases
de datos ofrecen mucha flexibilidad, escritura rápida, y consultas rápidas
gracias a su gran capacidad de indexación. Entre las BBDD documentales más
reconocidas encontramos la ya conocida por nosotros a MongoDb, de 10gen, y
CouchDB, de Apache.
También gozan de un gran reconocimiento en el mundo de las Bases de datos NoSQL
la RavenDB, de Hibernating Rhinos, BaseX, djondb, eXist, SimpleDB, de Amazon,
IBM Lotus Domino y Terrastore.
Bases de datos en orientadas a grafos
=====================================
Las bases de datos orientadas a grafos son excelentes herramientas para trabajar
datos complejos. Estas BBDD nos permiten representar los datos en estructuras de
grafos. Esto es de gran utilidad cuando los datos que vamos a procesar tienen
altos niveles de interrelación. Estas versátiles bases de datos, nos permite
ejecutar consultas y almacenamiento de datos de cualquier característica sin
siquiera preocuparnos por el volumen de los datos.
Gozan de un excepcional rendimiento para responder de forma eficiente al
análisis y consulta de volúmenes gigantescos de datos. Ofrece también una
diversidad de métodos analíticos y de consulta que la convierten en una de las
opciones más flexibles en NoSQL. Es bastante frecuente conseguir la
implementación de este modelo de BBDD en estructuras web de blogs. Twitter es
uno de los casos más relevantes donde una BBDD de Grafos está relacionada.
Las Bases de Datos orientadas a grafos también tiene otras funcionalidades que
no te puedes perder. Entre las marcas más reconocidas está nuestra ya conocida
Neo4j, pero esta no es la única. También están las conocidas HyperGraphDB,
InfoGrid, AllegroGraph, InfiniteGraph, Sones y DEX/Sparksee.
Bases de datos clave/valor
==========================
Las bases de datos clave valor son modelos no relacionales que utilizan un
método simple de almacenamiento de datos. Este tipo de BBDD toma los datos como
un conjunto de pares “clave-valor” en los que las claves cumplen funciones de
identificadores únicos.
Las claves o lo valores pueden ser cualquier tipo de datos. Pueden ser objetos
simples o complejos. Estas BBDD son altamente divisibles y brindan grandes
capacidades de escalabilidad horizontal.
Estos modelos de BBDD son uno de los preferidos de los clientes NoSQL, porque
son simples en cuanto a funcionalidad y brindan alto rendimiento a la hora de
ejecutar las lecturas y escrituras de datos. Ya hemos dado algunos ejemplos de
Bases de Datos Clave Valor como Cassandra y Redis, pero es obligatorio expandir
la lista cuando tenemos importantes BBDD como BigTable de Google, Dynamo de
Amazon, Project Voldemort de LinkedIn, OracleNoSQL y Riak.
Bases de datos multivalor
=========================
Las bases de datos multivalor son sistemas interesantes que incorporan
diferentes características multidimensionales y NoSQL para la clasificación y
manejo de los datos. Estas BBDD comparten significativas similitudes con los
modelos relacionales tradicionales. Ambos esquemas contienen tablas. Pero que
esto no te engañe, las BBDD multivalor proporcionan un esquema de trabajo menos
rígido.
Además de proporcionar mayor flexibilidad, los datos almacenados acá pueden
contener listas de valores. Esto quiere decir que cualquier dato almacenado
puede tener diversos valores asignados.
Estas bases de datos tienen un nivel de complejidad un poco más elevado debido a
que incorporan reglas de normalización para su diseño. Entre las BBDD multivalor
más conocidas podemos destacar Rocket D3 DBMS, Rocket mvBase DBMS, Rocket U2
Universe, Rocket U2 Unidata, OpenQM, Caché InterSystems, Reality, Jbase,
OpenInsight, Extensible storage engine.
Bases de datos tabulares
========================
Una BBDD tabular no es más que la estructuración de una BBDD en forma de tabla.
Incorpora elementos en columnas y líneas. Cada una de las celdas genera
intersecciones entre las columnas y las líneas. A estas intersecciones se le
asignan una numeración única para establecer un orden eficiente de los datos.
Están pensadas para grandes volúmenes de datos.
Estas tienen la capacidad de almacenar gran cantidad de datos dispersos. Entre
las principales DDBB de este estilo podemos conseguir a HBase de Apache que es
utilizada para soportar el servicio de mensajería de Facebook, también a
BigTable de Google y la versión abierta llamada LevelDB y a Hypertable.
Bases de datos de Arrays
========================
Las Bases de datos arrays sirven para trabar colecciones de datos conocidas como
raster data. Sitúan los datos en una cuadricula regular con más de dos
dimensiones. Estas bases de datos se utilizan para representar simulaciones,
sensores y datos estadísticos. Son capaces de manejar volúmenes de datos
importantes ofreciendo una flexibilidad y escalabilidad.
Estas bases de datos son consideradas una generación tecnológica emergente. De
las bases de datos más destacadas que trabajan este modelo podemos mencionar a
Oracle que ha profundizado sus trabajos en ella y SciDB, de Paradigm4.
Ejemplos y casos de uso de Bases de datos NoSQL
===============================================
Como vemos las BBDD NoSQL gozan de múltiples funciones, marcas, tipos y
ventajas. Ahora, es momento de poner más en contexto y mostrar algunos ejemplos
de su implementación.
A modo de ejemplo utilizaremos un JSON como el que conseguirás en mongoDB.
Veamos:
Supongamos que vamos a registrar diferentes personas en una colección
perteneciente a una BBDD NoSQL con algunos campos especiales. Estos no
necesariamente tienen que seguir un patrón específico como verás a continuación:
{
Nombre: «José»,
Apellidos: «Pérez Campo»,
Edad: 35,
Aficiones: [«vino»,»libros»,»ciclismo»],
Amigos: [
{
Nombre:»María»,
Edad:22
},
{
Nombre:»Luis»,
Edad:28
}
]
}
Ahora bien, si queremos añadir a otros datos de otra persona con algunas
características diferentes la podemos hacer sin mayor problema introduciendo lo
siguiente:
{ Nombre: "Luis",
Estudios: "Marketing y Publicidad",
Amigos:12
}
En un modelo relacional o SQL clásico esto sería imposible de hacer. Esta es una
de las tantas ventajas de las que te hemos hablado.
Esperamos que te sea de utilidad y te aventures a profundizar en el mundo de las
BBDD.
Fuentes
=======
-https://es.wikipedia.org/wiki/NoSQL
-https://www.grapheverywhere.com/bases-de-datos-nosql-marcas-tipos-ventajas/
=======
DBeaver
=======
Es una herramienta de base de datos universal gratuita y de código abierto para
desarrolladores y administradores de bases de datos.
Instalación
===========
Con snap:
$ sudo snap install dbeaver-ce
Como crear diagrama entidad relación en DBeaver
===============================================
https://blog.junglacode.org/gnu-linux/tips/como-crear-diagrama-entidad-relacion-en-dbeaver/
Fuente
======
https://dbeaver.io/about/
=========================================
Diferencia hay entre integer y biginteger
=========================================
La diferencia entre integer y biginteger radica en la cantidad de espacio que
ocupan en la base de datos y el rango de valores que pueden almacenar.
1. integer (o int): Tamaño en almacenamiento: 4 bytes.
Uso común: Es el tipo de dato más común para llaves primarias (id).
2. biginteger (o bigint): Tamaño en almacenamiento: 8 bytes.
Uso común: Para valores que requieren un rango mucho mayor, como grandes
identificadores, conteos de visitas, o valores financieros que pueden exceder el
rango de integer.
¿Cuándo usar cada uno?
======================
integer: Es más eficiente en cuanto a uso de memoria y almacenamiento. Se usa
cuando sabes que los números no serán muy grandes (como para la mayoría de las
identificaciones de registros o conteos que no superan los dos mil millones).
biginteger: Es útil cuando necesitas trabajar con números extremadamente
grandes, como en sistemas que gestionan enormes bases de datos o cifras, como el
número total de visitas a una página popular, cifras financieras globales, o
sistemas que necesitan grandes valores de identificación.
Ejemplo práctico:
Si esperas que un id en una tabla nunca superará los dos mil millones, puedes
usar integer.
Si trabajas en un sistema donde el conteo de algo (como transacciones o
usuarios) podría llegar a cifras astronómicas, usarías biginteger.
Fuente
======
ChatGPT
===========================
Índice en una base de datos
===========================
Es una estructura de datos que mejora la velocidad de las operaciones de
búsqueda y consulta en una tabla. Se puede pensar en un índice como un índice
de un libro: permite encontrar información específica rápidamente, sin necesidad
de revisar cada página.
¿Qué es un índice?
==================
Un índice almacena una copia ordenada de ciertos campos (columnas) de una tabla,
junto con un puntero a la fila correspondiente en la tabla original. Esto
permite a los sistemas de gestión de bases de datos (DBMS) localizar datos más
rápido.
¿Cómo funcionan los índices?
============================
Cuando se crea un índice, el DBMS organiza los datos del índice de forma que las
búsquedas sean eficientes. Esto normalmente se hace utilizando estructuras de
datos como:
Árboles B (B-trees): Muy comunes, mantienen los datos en orden y permiten
búsquedas, inserciones y eliminaciones eficientes.
Hashing: Útil para búsquedas exactas, pero no para rangos.
Bitmap: Se usa en bases de datos analíticas para campos con pocos valores
distintos.
Cuando realizas una consulta, el DBMS puede usar el índice en lugar de escanear
toda la tabla para encontrar las filas correspondientes, lo que reduce
drásticamente el tiempo de ejecución.
Tipos de índices
================
Índice primario: Se basa en la clave primaria de la tabla, que debe ser única
para cada fila.
Índice único: Asegura que los valores de la columna o combinación de columnas
indexadas sean únicos.
Índice compuesto: Cubre múltiples columnas.
Índice de texto completo: Diseñado para búsquedas en grandes volúmenes de texto.
Índice de clúster: Ordena físicamente las filas de una tabla según el índice.
Índice no agrupado (non-clustered): No afecta el orden físico de los datos, pero
incluye punteros a los registros reales.
Ventajas de los índices
=======================
Mejora del rendimiento: Hacen que las búsquedas, clasificaciones y filtros sean
más rápidos.
Optimización de consultas: Reduce el tiempo de ejecución en operaciones comunes
como SELECT.
Desventajas de los índices
==========================
Espacio adicional: Los índices ocupan espacio en disco.
Impacto en escrituras: Inserciones, actualizaciones y eliminaciones son más
lentas porque los índices deben actualizarse.
Complejidad de administración: Un exceso de índices puede contrarrestar sus
beneficios.
Cuándo usar índices
===================
En columnas que se utilizan frecuentemente en consultas WHERE, JOIN, o ORDER BY.
En columnas con alta cardinalidad (muchos valores únicos).
No deben usarse en tablas pequeñas o columnas con pocos valores distintos, ya
que el costo de mantenimiento puede superar el beneficio.
Un buen diseño de índices es clave para optimizar el rendimiento de una base de
datos.
Ejemplo de índice en una base de datos
======================================
Supongamos que tienes una base de datos para una biblioteca con una tabla
llamada Libros:
id titulo autor año_publicacion
1 Don Quijote Miguel de Cervantes 1605
2 Cien Años de Soledad Gabriel García Márquez 1967
3 Hamlet William Shakespeare 1603
4 La Odisea Homero -700
5 Matar a un Ruiseñor Harper Lee 1960
Ahora, tienes una consulta que busca libros por el autor:
SELECT * FROM Libros WHERE autor = 'Homero';
Sin un índice: Si no hay un índice en la columna autor, el DBMS tiene que leer
cada fila de la tabla y comparar el valor de autor con 'Homero'. Esto se llama
un escaneo completo de tabla (full table scan), y puede ser muy lento si la
tabla tiene miles o millones de filas.
Creando un índice, puedes crear un índice en la columna autor:
CREATE INDEX idx_autor ON Libros(autor);
Este índice crea una estructura de datos ordenada basada en los valores de la
columna autor:
autor | puntero a id
Gabriel García Márquez 2
Harper Lee 5
Homero 4
Miguel de Cervantes 1
William Shakespeare 3
Con un índice: Cuando ejecutas la misma consulta ahora:
SELECT * FROM Libros WHERE autor = 'Homero';
El DBMS utiliza el índice idx_autor para localizar rápidamente el valor 'Homero'
en la estructura ordenada. Una vez que encuentra el valor, sigue el puntero al
registro en la tabla Libros para obtener toda la fila.
Resultados de rendimiento
Sin índice: Tiene que revisar todas las filas, lo cual toma más tiempo.
Con índice: Encuentra la fila en una fracción del tiempo, especialmente si la
tabla es grande.
Conclusión: Los índices son como atajos que el DBMS utiliza para buscar datos
rápidamente, pero debes usarlos de forma estratégica para equilibrar el
rendimiento de lectura y escritura.
Consultar los índices en PostgreSQL, ver guía de PostgreSQL
Fuente
======
ChatGPT
=========================
Clúster en Bases de Datos
=========================
Un clúster de bases de datos implica múltiples servidores o nodos que colaboran
para almacenar, administrar y procesar datos. Dependiendo del propósito, los
clústeres de bases de datos pueden configurarse de varias maneras.
Tipos de Clústeres en Bases de Datos:
-Clúster de Alta Disponibilidad:
Diseñado para garantizar que la base de datos esté siempre disponible, incluso
si hay fallas en uno o más nodos.
Ejemplo: PostgreSQL con Patroni para alta disponibilidad.
-Clúster de Replicación:
Crea copias de la base de datos en múltiples nodos para permitir consultas
distribuidas o respaldo.
Ejemplo: MySQL con Master-Slave Replication.
-Clúster de Particionamiento (Sharding):
Los datos se distribuyen entre diferentes nodos, dividiendo la base de datos en
partes más pequeñas (shards).
Ejemplo: MongoDB con Sharding.
-Clúster de Almacenamiento Distribuido:
Los datos se dividen y se almacenan en diferentes nodos, permitiendo escalar
horizontalmente.
Ejemplo: Apache Cassandra o Amazon Aurora.
PostgreSQL: Clúster de Bases de Datos
En PostgreSQL, un clúster de base de datos no implica múltiples servidores, sino
un conjunto de bases de datos administradas por un único servidor PostgreSQL.
Todas las bases de datos en el clúster comparten configuraciones comunes y se
encuentran en el mismo directorio de datos.
Ventajas de un Clúster
======================
Escalabilidad: Los clústeres permiten manejar mayores volúmenes de datos o
solicitudes al agregar más nodos.
Tolerancia a fallos: Si un nodo falla, otros pueden asumir su carga.
Rendimiento: La distribución del trabajo reduce la sobrecarga en nodos
individuales.
Alta disponibilidad: Se garantiza que el servicio esté siempre disponible.
Ejemplo Práctico: Clúster de Alta Disponibilidad en PostgreSQL
==============================================================
Un clúster de PostgreSQL puede configurarse con herramientas como:
Patroni: Coordina la replicación y la conmutación por error automática.
PgBouncer: Para balancear conexiones.
ETCD o Consul: Usados como sistemas de orquestación.
Así, el clúster puede manejar fallos automáticamente y continuar sirviendo las
consultas sin interrupciones significativas.
En resumen, los clústeres son fundamentales para garantizar rendimiento,
escalabilidad y disponibilidad, tanto en computación como en bases de datos.
Fuente
======
ChatGPT