khan - ¿Cuándo debo usar C++ en lugar de SQL?
sql course (8)
He discutido esto con mis colegas, y también me empujan a usar C ++, diciendo que SQL no es para análisis complejos sino principalmente para importar (de las tablas existentes) y exportar (a nuevas tablas) datos, y un poco más como fusionar datos para, por ejemplo, tablas unidas.
Esto es completamente arbitrario. Aprende SQL. Hay muchos recursos disponibles en la web de forma gratuita.
Soy un programador de C ++ que ocasionalmente usa MySQL para trabajar con bases de datos, pero mi conocimiento de SQL es bastante limitado. Sin embargo estoy seguro que estoy dispuesto a cambiar eso.
En este momento estoy tratando de hacer un análisis (!) De los datos que tengo en mi base de datos únicamente con consultas SQL. Pero estoy a punto de rendirme, y en lugar de eso, importo los datos a C ++ y hago el análisis con el código C ++.
He discutido esto con mis colegas, y también me empujan a usar C ++, diciendo que SQL no es para análisis complejos sino principalmente para importar (de las tablas existentes) y exportar (a nuevas tablas) datos, y un poco más como fusionar datos para, por ejemplo, tablas unidas.
¿Puede alguien ayudarme a dibujar una línea? ¿Entonces sé cuándo cambiar a C ++? Por supuesto, el rendimiento también es un problema.
¿Cuáles son las indicaciones de que las cosas se complican en SQL? O tal vez simplemente tome el enfoque equivocado al diseñar las consultas. Entonces, ¿dónde puedo encontrar tutoriales, libros, ... para tener un mejor enfoque?
Espero que esto no sea demasiado vago. Estoy realmente un poco perdido.
En mi opinión, solo debe realizar un análisis en C ++ si el servidor de base de datos no proporciona un equivalente para la función de análisis. Como los servidores de base de datos son muy inteligentes y es difícil y casi imposible superar la eficiencia del algoritmo de la función de análisis del servidor de base de datos. También traer datos sin procesar a la aplicación para realizar análisis también incluye muchos gastos generales.
Si en algún punto el SQL simple se vuelve demasiado complejo, la PL nativa del servidor podría ser una buena opción
Estoy de acuerdo con JNK y Jochai, pero no estoy de acuerdo con Ascanio. Es mejor mejorar el conocimiento en sistemas de bases de datos. Sql viene con eso
Generalmente, SQL es muy eficiente al manejar su propia base de datos (depende de la implementación del servidor).
Debe utilizar consultas para analizar la base de datos.
La principal razón para eso sería la sobrecarga de comunicación.
Incluso si el servidor está en la máquina local (los servidores remotos tendrían una sobrecarga de comunicación obvia), aún tendrá que recuperar la información almacenada desde el servidor SQL a su programa c ++ para su análisis.
Ahora, si tiene 10000s de líneas en el SQL, tendría que conseguir que el servidor SQL las lea todas y las envíe a su programa donde probablemente crearía una copia local de los datos para que pueda trabajar.
Si deja que el servidor SQL lo haga con las consultas, obtendrá las complejas optimizaciones que realiza según el tipo de consulta que esté ejecutando, y al final solo puede recuperar una cantidad limitada de datos (la que realmente necesita) A través de la comunicación.
Por lo tanto, esto es algo en lo que he estado pensando y me parece que SQL, como solo una plataforma / lenguaje para almacenar / manipular datos, no debería tener una ventaja inherente sobre una biblioteca C ++ o C. Me parece que, en teoría, se podría construir una biblioteca en C ++ tan eficiente, si no más eficiente, que SQL al hacer esto. Al hacerlo, podrá construirlo desde cero, en términos de cómo se almacenan los ints, caracteres, cadenas y otros tipos de datos, y facilitar la interfaz con su aplicación particular (como el desarrollo web). Incluso podría hacerlo para que las consultas se realicen en un lenguaje como javascript (lo que permite a los desarrolladores web centrarse solo en aprender un idioma muy bien).
Puede hacer un análisis muy complejo de los datos en SQL, siempre que sepa cómo usar las características que ofrece SQL.
SQL tiene características para realizar operaciones relacionales, como uniones y proyecciones. También para realizar operaciones de conjuntos como unión, intersección y restricción (subconjunto). También para hacer aritmética básica en números, como los cuatro operadores aritméticos, y funciones incorporadas como SQRT. También funciones estadísticas como COUNT, SUM y AVG que pueden combinarse con proyecciones de formas muy interesantes. Un buen DBMS le permitirá ampliar las funciones integradas con sus propias funciones escritas en C, C ++ o quizás PL / SQL.
El poder que obtiene de estas características depende de qué tan bien diseñada esté la base de datos. Una base de datos bien diseñada se ajusta al modelo relacional y debe ser relevante para el uso previsto de los datos.
El código SQL se puede almacenar en la base de datos en los productos almacenados. Se puede almacenar en archivos de script SQL. Y, como ya sabe, se puede incrustar en programas de aplicación. Además de SQL, puede usar herramientas OLAP y generadores de informes para hacer cosas estándar con los datos con mucha facilidad.
Las personas que te aconsejan que mantengas todo tu procesamiento en C ++ parecen haber aprendido lo suficiente como para usar una base de datos como un sistema de archivos grande y estúpido. Un buen DBMS es mucho más que eso.
SQL sobresale en el análisis de grandes conjuntos de datos relacionales .
El lugar para trazar la línea es la escala de su análisis.
Si analiza registros individuales uno por uno, hágalo en su aplicación.
Si analiza grandes conjuntos de registros como una unidad, SQL es definitivamente la mejor herramienta para ese trabajo.
El análisis fila por fila no es algo para lo que SQL esté diseñado u optimizado muy bien. Pero, si desea saber algo sobre un grupo de datos de un millón de filas, hágalo en la base de datos.
Tomó la decisión correcta para comenzar el análisis de datos con SQL. Ahora, cuando siente que su conocimiento de SQL lo limita, tiene 2 opciones: renunciar y volver a utilizar el conjunto de herramientas conocidas (pero no muy eficientes) (C ++) o elevar su nivel con SQL.
Es posible que en algún momento el SQL se vuelva demasiado complejo también, pero C ++ tampoco será la respuesta, probablemente algunas herramientas especializadas.