2010-08-25 17 views
5

Quería recibir los comentarios de la comunidad sobre la elección de idioma que nuestro equipo desea realizar en el futuro cercano. Somos un desarrollador de software y trabajo en un equipo de DBA de Oracle y SQL Server que admite una aplicación Java multiplataforma que se ejecuta en Oracle Application Server. Contamos con bases de código SQL Server y Oracle, y ofrecemos soporte a clientes en servidores Windows, Solaris y Linux.¿Qué lenguaje de scripting de plataforma cruzada debemos adoptar para un grupo de DBA?

Muchas de las tareas que hacemos con frecuencia no están lo suficientemente automatizadas, y en donde están, tienden a ser mucho más automatizadas a través de scripts de shell, con poca funcionalidad equivalente en Windows. Desafortunadamente, ahora tenemos este problema de desarrollar scripts y demás en dos plataformas. Por lo tanto, deseo que elijamos un lenguaje multiplataforma para el script, en lugar de utilizar Bash y traducir torpemente a archivos Cygwin o Batch cuando sea necesario.

Se tendría que ser:

  1. dinámico (por lo que no sugiere Java o C!)
  2. fácilmente disponibles en cada plataforma (Windows, Solaris, Linux, tal vez AIX)
  3. Exigir muy poco en la forma de instalación (¡el acceso raíz no siempre está disponible!)
  4. Sea fácil para los scripters de shell, es decir, los DBA, para adoptar, que no sean desarrolladores hardcore.
  5. Sea fácil de entender código de otras personas
  6. Amable con SQL Server y Oracle, sin perder el tiempo.
  7. Algunas características agradables de XML no irían mal.

Sería preferible si se ejecutan en la JVM, ya que esto casi siempre se va a instalar en cada servidor (por cierto en todos los servidores de aplicaciones) y tenemos muchos desarrolladores de Java en nuestra empresa, por lo que se pegue a la JVM tiene sentido. Esto no es exclusivo, ya que sé que Python es un lenguaje muy viable aquí.

He creado una lista de opciones, pero puede haber más: Groovy, Scala, Jython, Python, Ruby, Perl.

Nadie tiene mucha experiencia en ninguna, excepto que tengo bastante experiencia con Java y Groovy. Estamos buscando algo dinámico, fácil de utilizar, funcionará sin problemas con el servidor SQL y Oracle, tiene algunas funciones de simplificación de XML, y eso no será un obstáculo para los DBA. Muchos de nosotros estamos muy orientados a Bash, ¿qué podría alejarnos de esta adicción?

¿Cuáles son las opiniones de las personas sobre esto?

gracias!

Chris

+2

Marcado como subjetivo, ya que "En mi opinión, dar una respuesta correcta a una pregunta de este tipo solo puede ser subjetiva, ya que todos los candidatos son perfectamente válidos". En otras palabras, elija la que desee, ya que todas tienen todas las características que desea. – Riduidel

+0

@Riduidel es correcto; no hay una respuesta correcta para esta pregunta. Jython (que es Python en la JVM) funcionará. Así que básicamente cualquier otro lenguaje de scripting. – katrielalex

+0

Estoy de acuerdo, no hay una respuesta correcta. Solo quiero obtener algunas ideas sobre cómo es trabajar con cada uno de los idiomas en este tipo de envolvimiento. Obviamente, es subjetivo, pero también será para cada uno de nuestros DBA, por lo que encontrar algo cómodo para todos es lo más desafiante. –

Respuesta

3

Si desea un lenguaje dinámico y ya hay muchos desarrolladores de Java en su empresa, entonces Groovy parece una elección obvia, ya que es muy fácil para los desarrolladores de Java retomar (también, dijo que tiene algo de experiencia en Groovy)

Groovy se ejecuta en la JVM y tiene excelente support for working with XML. También proporciona una sintaxis muy simple para working with relational databases.

Viene con una consola y un shell (aunque nunca uso el shell) que hacen que sea muy fácil probar/ejecutar scripts o fragmentos de código Groovy.

+0

Hemos decidido darle una oportunidad a groovy para comenzar, por varias razones principales: 1) Estamos soportando una aplicación Java, y Groovy es muy similar sintácticamente e involucra el mismo tipo de decisiones de diseño. 2) Tiene cosas que hacen que las secuencias de comandos básicas sean sencillas, y también le permiten aprovechar las bibliotecas de Java para hacer que las cosas sean más funcionales. 3) Puede hablar sobre JMX y JDBC, por lo que tenemos la oportunidad de controlar los servidores de aplicaciones con él y utilizar técnicas de acceso a la base de datos bien admitidas y bien utilizadas. 4) ¡Demostré algunas cosas en Groovy al equipo! Gracias por sus sugerencias y ayuda. –

1

Aunque Prefiero trabajar en la JVM, una cosa que me apaga es tener que girar una JVM para ejecutar un script. Si puedes trabajar en un REPL, esto no es tan importante, pero realmente te ralentiza al hacer scripts de edición y ejecución de depuración.

Ahora, por supuesto, Oracle tiene muchas cosas de Java donde se necesita más interacción, pero eso es algo que solo se puede calcular lo importante que es. Para el trabajo simple de Oracle DB he visto muy poco Java y mucho fo PLSQL/SQL.

Si su dba ahora hace su trabajo en bash, es muy probable que se retiren en poco tiempo, ya que existe una ruta de progresión lógica y agradable.

Dado que el ruby ​​fue diseñado para ser una versión mejorada de perl, también cabría en esa categoría. En realidad, Python también.

Scala está tipado estáticamente como Java, aunque con mucho mejor tipo de inferencia.

Mi recomendación sería ir por la ruta Perl. El CPAN es su as en el hoyo, no tiene que lidiar con las cosas OO que podrían desactivar algunos DBA (aunque está ahí para los usuarios avanzados).

+0

+1 para Perl. Es ideal para este tipo de cosas. –

+0

Perl es el lenguaje de scripts tradicional sysadmin. ¿Cómo es en Windows? También me resulta un poco difícil leer el código ... aunque tiene sentido para algunos :) –

+1

El lanzamiento de Activeperl o los lanzamientos de cygwin funcionan bien en Windows, uno es más plano y el otro más unixy. Se necesita algo de tiempo para acostumbrarse, pero la programación de crossform es realmente sólida, y la comunidad perl tuvo mucho tiempo para resolver las arrugas. Las expresiones regulares son difíciles de leer en cualquier idioma, y ​​sí Perl tiende a "promover" un estilo de programación de solo escritura. Ahora, al escribir scripts con un gran porcentaje de scripts de tirar, esto no es necesariamente algo malo. –

0

He estado en una situación similar, aunque a pequeña escala. La situación anterior era que cualquier automatización en las bases de datos de SQL Server se realizaba con VBScript, que comencé a utilizar. Como quería algo multiplataforma (y menos molesto que VBScript) fui con Python.

Lo que he aprendido es:

  • Obviamente, usted quiere un lenguaje que incluye bibliotecas para acceder a sus bases de datos con comodidad. No me preocupaba demasiado abstraer las diferencias (es decir, todavía escribía consultas SQL en el dialecto relevante, con parámetros). Sin embargo, estaría un poco menos contento con PHP, por ejemplo, que tiene solo bibliotecas y funciones muy específicas del proveedor para ciertas bases de datos. Veo que no está en tu lista.
  • EL principal obstáculo era la autenticación. Si su SQL Server usa la autenticación de dominio de Windows, tendrá que trabajar para entrar. Otro sistema también tenía necesidades específicas, ya que requería tokens RSA para ser compatibles.

Para el segundo punto, Python es bastante versátil para evitar las dificultades, pero se estaba metiendo en un territorio "mal soportado", especialmente en Windows. Fue fácil evitar el primer problema de un host de Windows, y para un host de Unix es posible aunque no fácil. Si está utilizando la autenticación de SQL Server, se vuelve mucho más fácil.

De sus otras opciones, esperaría que existieran varias formas de autenticación y controladores de bases de datos para Perl, lo que filosóficamente sería más fácil para los DBA utilizados para shell scripting. Ruby: sin experiencia, pero tiende a tener soporte irregular para algunos de los métodos y conectores de autenticación más antiguos. Scala Esperaría ser demasiado un "lenguaje de programación de programador" - OOO y FP? Es un lenguaje muy interesante, pero tal vez no el que elegí al principio. En cuanto al resto de las opciones basadas en Java, no tengo una opinión, pero compruebo que todos los tipos de conexión que desea realizar son sólidamente compatibles.

+0

¡Gracias! En este momento, la autenticación no es un problema importante, generalmente usamos la autenticación de SQL Server. Sin embargo, hay al menos un sitio que usa autenticación AD para SQL Server, por lo que puedo ver que esto causa un problema en algún momento. Puede valer la pena tenerlo en cuenta. Dado que todos los clientes son gobiernos locales, todos tienen sus propias políticas de seguridad. Y sí, es una pesadilla :) –

+0

"... la autenticación no es un problema importante ... todos los clientes son del gobierno local ..." Shudder. –

+0

Creo que leyó mal;) –

5

Puede optar por Python. Su dinámica (interpretada), está disponible en Windows/Linux/Solaris, tiene una sintaxis fácil de leer para que el mantenimiento de su código sea fácil. Hay módulos/bibliotecas para la interacción de Oracle y varios otros servidores de bases de datos también. también hay soporte de biblioteca para XML. Los 7 puntos están cubiertos.

+0

Me gusta Python, pero no estoy seguro de su estado en Solaris. Sé que Solaris 10 viene con paquetes nativos, pero las versiones anteriores no. ¿Es fácil obtener una configuración de python sin repetición sin acceso a la raíz? –

+1

solo necesita instalarlo en un directorio. El resto es solo para configurar la ruta del intérprete y las rutas de la biblioteca, eso es todo. – ghostdog74

4

Lo XML casi llama a Scala. Ahora, me encanta Scala, pero sugiero Python aquí.

5

Creo que las tres mejores opciones son Groovy, Python y Scala. Los tres le permiten escribir código en un nivel alto (en comparación con C/Java). Python tiene sus propios enlaces de base de datos perfectamente adecuados, y Groovy y Scala pueden usar los creados para Java.

Las ventajas de Python son que ya se usa ampliamente, por lo que hay toneladas de herramientas, bibliotecas, experiencia, etc. disponibles a su alrededor. Tiene una sintaxis particularmente limpia, lo que hace que trabajar con ella sea estéticamente agradable. Las desventajas son que es lenta (lo que puede no ser un problema para usted), sin tipo (por lo que tiene errores de tiempo de ejecución en lugar de errores de tiempo de compilación), y realmente no se puede alternar entre Jython y Python, por lo que tiene que elegir si desea la gran cantidad de cosas de Python, o la gran cantidad de material de Java, menos muchas cosas buenas de Python.

Las ventajas de Groovy son que ya lo conoce y funciona bien con las bibliotecas de Java. Sus desventajas son también la lentitud y la falta de tipado estático. (Entonces, a diferencia de Python, la elección es: ¿valora más la sintaxis clara de Python y su amplia adopción, o valora más el vasto conjunto de bibliotecas Java en un lenguaje hecho para funcionar bien en ese entorno?)

The Las ventajas de Scala son que está tipado estáticamente (es decir, si el código supera el compilador, tiene una mayor probabilidad de funcionar), es rápido (tan rápido como Java si le interesa trabajar lo suficiente) e interopera bien con las bibliotecas de Java. . Las desventajas son que le exige un poco más de trabajo para hacer que el trabajo de tipado estático (aunque mucho, mucho menos que Java, mientras que al mismo tiempo sea más seguro), y que el estilo canónico de Scala sea un híbrido objeto/combinación funcional que se siente más diferente a los otros dos (y por lo tanto requiere más entrenamiento para usar con efectividad total IMO). En contraste con Groovy, la pregunta sería si la familiaridad y la facilidad para comenzar son más importantes que la velocidad y la corrección.

Personalmente, ahora realizo casi todo mi trabajo en Scala porque mi trabajo requiere velocidad y porque el compilador detecta ese tipo de errores en la codificación que yo hago comúnmente (por lo que es el único lenguaje que uso donde estoy No me sorprende cuando grandes bloques de código se ejecutan correctamente una vez que los compilo). Pero he tenido buenas experiencias con Python en otros contextos: la interfaz con bases de datos grandes parece un buen caso de uso.

(Yo descartaría que Perl sea más difícil de mantener sin beneficios significativos sobre, por ejemplo, Python, y descartaría que Ruby no sea más poderoso que Python para garantizar la sintaxis menos intuitiva y la menor tasa de adopción/disponibilidad de herramienta.)

Cuestiones relacionadas