No separar valores VARCHAR en función del tamaño tienen una ganancia de rendimiento?

Question

Estoy trabajando con un equipo que está tratando de implementar un sistema de EAV. Ellos han decidido dividir las tablas de atributo-valor por tipo y que se debate el uso de diferentes tablas para diferentes rangos de tamaño de varchar.

EX:

• table_1 - hasta varchar (10)
• table_2 - varchar (11) a VARCHAR (500)
• table_3 - varchar (501) a VARCHAR (MAX)

Siempre he tenido la impresión de que varchar sólo se iba a utilizar el tamaño que necesita.

¿Usted sabe si esto va a tener cualquier ganancia en el rendimiento y valdría la pena el extra de codificación / lógica que sería necesaria?

Answer 1

Mi instinto dice que cualquier ganancia en el rendimiento que se obtiene es poco probable que sea la pena la molestia adicional (y el potencial de los insectos) como resultado de la necesidad de hacer cumplir la separación y realizar múltiples búsquedas en su lógica de la aplicación.

Si usted tiene una gran cantidad de pequeños valores, siendo solamente consulta de ellos y no del resto se podría ver alguna mejora en el rendimiento a medida que más filas encajarían en cada página, de modo en general tendrán que ser procesados ??en la memoria RAM o leer desde el disco para una consulta determinada menos páginas. Tan pronto como se necesita todas las propiedades de una sola vez (o simplemente una mezcla) este beneficio se va a perder la cabeza fuera del agua, ya sea por necesidad de consulta varias tablas por separado oa través de un sindicato.

La única manera de estar seguro, por supuesto, es montar un gran conjunto de datos razonablemente realista y ejecutar algunas pruebas de rendimiento contra los arreglos que está considerando. Pero dudo mucho verá ningún cambio digno de la complejidad adicional. Si ustedes, los datos se pueden dividir en formas más lógicas (es decir, formas implícitas en la lógica de negocio) que le sugiero que busque en la partición de datos, sobre todo si se puede dividir las particiones en diferentes unidades. Siempre que se encuentre contemplando una optimización cargados potencialmente complejidad (incluyendo particiones) siempre volver atrás y reconsiderar su estructura global de datos y asegurarse de que no está trabajando en contra de la lógica de negocio y comprobar su hardware es suficiente para la carga que se puede esperar - si bien no es la garantía de que es probable encontrar mucho más significativas ganancias a través de mirar en estas áreas centrales en su lugar.

Answer 2

No tendrá ningún ganancias en el rendimiento en absoluto.

pensamientos rápidos, no es en absoluto un análisis exhaustivo:

• En algún momento tendrá que UNIÓN estos para obtener una visión única y luego todo se vuelve varchar (max)
• ¿Cómo se decide la longitud en la delantera?
• La indexación para buscar valores? No se puede indizar> 900 bytes
• rodar sus propias limitaciones "únicos" en una EAV sería bastante malo, sin dividido en varias tablas

EAV contra el patrón : hay varios artículos sobre cómo evitar EAV

Answer 3

Parece que están tratando de optimizar la EAV para las búsquedas. Sin embargo, esto suena claramente como que no está tratando de optimizar un sistema de deficiencias perfilados, pero en su lugar están tratando de optimizar a través de conjeturas vudú.

Recordarles que la primera regla de optimización está perfilado, así como David Spillett dijo, hasta que tenga un par de cientos de millones de filas en la EAV (teniendo en cuenta la mayoría de las entidades que conozco son al menos 15 atributos en-toto por lo que sólo lo haría obtener como unas pocas decenas de millones de entidades) y, a continuación, no es posible saber que esto tendrá impacto alguno.

Voy a ir con "no, esto no beneficiará al igual que creo que va a" y que la mejor partición probablemente sería algo del orden de 50 caracteres y 100 caracteres en lugar de 10 y 500. Pero eso es sólo una adivinar.

---

Pero aviso que tendrá el efecto que quieren en la que va a permitir un mejor índice de rendimiento (todo el particionamiento de datos debe dar un mejor rendimiento de la indexación sobre la partición no como una regla general)