node ha llegado para quedarse (y express de la manita), mongo mas de lo mismo, angular lo dudo xD a nivel de backend hay mas estabilidad, en frontend es todo una puta mierda, no he visto nada peor, gracias a typescript y librerías como rx o ramda se hace todo algo mas fácil y entretenido
Otro hilo más donde cada uno barre para su casa.
#1 Yo no voy a entrar en las peleas de quien la tiene más larga. Te puedo garantizar que Angular v4 (que sale ahora en Marzo) es lo mismo que lo que hay ahora con Angular v2. Tendrá algún breaking change pero nada que no se pueda aprender en un par de horas.
#33 Malditos proAJS xddd
Me han dado 4 meses para trastear con stacks de momento estoy tirando MEAN y MERN haciendo la misma tarea y MEAN me ha dado sida, con MERN es más llevadero.
Quizás más tarde pruebe con MySQL + L5.3 + VueJS.
#35 Que sirve para grandes (de verdad) cantidades de datos. El problema es que la usan hasta para la web de la panadería del barrio porque es cool.
#37 Es que es eso, veo a muchos que si mongoDB que si tal y cual pero por ejemplo para los datos donde yo trabajo (universidad) y que precisamente muchas tablas de uso normal se usan también como históricos (fecha_alta, fecha_fin) no hemos tenido problemas con la Oracle. Estamos hablando que cada año hay miles de personas de alta y las antiguas pues pasan de curso etc... y la universidad lleva muchos años con datos de usuarios.
Quiza lo instale e intente probar algo, pero solo para aprender un poco como funciona pero vamos no se.
Yo he estado tb con grandes cantidades de datos en MySQL (una tabla de 10millones de registros) y a partir de los 5 millones, ya le costaba a mysql trabajar con esa tabla xD (además, también depende al final de las querys, los indices, las relaciones foraneas, la máquina donde esté, etc... )
Aun así, supongo que sobre el mismo hardware, Oracle daría mejor resultado, pero con MongoDB no sabría por donde buscar o donde encontrar alguna prueba con bases de datos grandes...
Creo que buscaré alguna base de datos que tenga actualmente con muchos registros e intentaré hacerme un script que la migre a mongoDB y hacer algunas pruebas..
#39 Pues yo tengo actualmente 7.700.00 registros en total en MySQL y tira bastante bien, en algún mass loading si que me tarda un poco pero es bastante comprensible cuando cargas más de 200 orders con sus respectivos productos.
Como podría migrar esto a MongoDB para trastear? Voy a buscar en google xD
#40 Yo hablaba de una tabla dentro de la base de datos, es decir, cuando una misma tabla tiene +5 millones de registros
Aun asi, teniendo 7,7millones en total, debes de tener alguna tabla grande ( o 68mil filas por tabla xDD )
Sobre la migración, habia pensado en hacerme un script y conectarme a cada tabla en mysql y migrarla a mongo registro por registro y que tarde lo que tarde... Desconozco si hay alguna manera de migrar un backup de mysql directamente a mongodb, pero con tantos gb, no me termino de fiar nunca xD
#42 No veo el problema la verdad, cual usas tu?
A mi para todo lo que he hecho me ha bastado con phpmyadmin, asi que nunca me he molestado en buscar alternativas xD
#42 Llora:
phpMyAdmin
Version information: 3.1.2Apache
MySQL client version: 5.1.73
Es en el servidor de producción, a ver quién es el majo que hace un upgrade, en local suelo utilizar adminer pero me sigue gustando PHPMyadmin :p
#33 Te equivocas, yo no le he dicho que use MEAN contra LAMP, he resuelto una duda que tenia el chaval, nada más.
A mi me da igual que use Angular, react o PHP, lo único es que decida lo que decida, que al menos tenga las respuestas a sus preguntas.
De la manita de google muy mal se tiene que dar la cosa para que Angular no tenga futuro.
#43 Si tienes una tabla de 10 millones de registros con problemas hay bastantes que hay que tener en cuenta, slow queries, tablas mal indexadas, consultar sin cachear, etc . Cambiar a mongodb porque las consultas a tu base de datos son lentas no es la solución aunque es lo que hace la mayoría al no entender el problema de base. 10M de registros en una tabla bien implementada en un sistema relacional no es nada.
#48 La idea no es cambiar una base de datos mysql a mongodb por problemas, la idea era copiar una base de datos con muchos registros para hacer las pruebas en mongodb.
Sobre lo otro, como comentas, hay muchas cosas que afectan al rendimiento de la tabla y seguramente muchas se puedan mejorar. Actualmente no tengo ese problema, ya que hablo de una experiencia pasada, por lo que tampoco te puedo decir que es exactamente lo que fallaba, pero supongo que, aun con todo bien configurado, siempre habrá algún límite que otros motores, como Oracle, seguramente puedan mover correctamente.
MongoDB no es para grandes cantidades de datos, si no, no recomendarían que de hardware elijas uno en el que quepa todo en RAM... foursquare utiliza mongo, pero es lo de siempre, necesitas indices como en Mysql... ellos por lo que tengo entendido tienen algo en el código que si una query no usa un indice, no compila. (Al menos eso dicen).
En el otro extremo esta Youtube, que utiliza mysql para todo lo que tiene que ver con metadata de los videos, y el mayor problema que tienen, es con los cambios en el esquema ("ventaja" para todas las schemaless...)
#50 ojo con las geoqueries que en mongo no van muy bien... sobre todo cuando te acercas a los polos.
Creo que hay muchas cosas muy poco claras aquí.
Primeramente, no veo por qué Angular 2 esté de capa caída. ¿De dónde sacáis eso? Lo que pasa es que es un framework con una curva de aprendizaje nada fácil, y su documentación deja bastante que desear. Pero la funcionalidad es tremenda y deja hacer muchas cosas. Yo lo único que le veo mal, es que te obliguen a usar Typescript.
En segundo lugar, está el asunto de Node, que tampoco entiendo por qué se ve tan mal. A mí me parece una forma terriblemente sencilla de programar el backend, qué queréis que os diga.
Por otra parte, ojo con React porque pese a que está muy bien, puede llegar a ser difícil de mantener, además de que al final la mayoría del proyecto son dependencias xD.
#52Zerokkk:Yo lo único que le veo mal, es que te obliguen a usar Typescript.
¿Y esa no es la parte buena? xD
No.
Typescript tiene sus cosas buenas. Por ejemplo, creo que si estás trabajando en un equipo grande, de más que un puñadito de personas, está bien tener tipos ya que el código es mucho más fácil de leer. Pero si sois 4 o 5 pelagatos, y os entendéis bien, no hace falta tener tipados.
La gracia de JS es programar cosas rápido, con mucho dinamismo, y los tipados al final sólo te ralentizan todo el proceso. Yo, que soy javero y siempre gusté de ver tipos, la verdad que detesto bastante verlos en JS ya que me da la sensación de que se carga una de las ventajas del lenguaje.
Además de que el linter de TS hace que no puedas hacer algunas cosas, vaya xD.
En definitiva: teniendo ES6, no veo el sentido a TS. Y cuando salga ES7 y el async/await, va a ser la repolla en vinagre.
#54 Que yo tenga entendido, no te obliga a usar TS..
Gente que trabaja en Angular, ya te dicen que no empieces con Angular 2.
#54 Y si alguno del equipo te cae mal? en plan, eramos 6 integrantes en el equipo y llevábamos 6 meses trabajando en un proyecto utilizando un lenguaje de tipado estático pero nos enfadamos con él y lo expulsamos del equipo. Nos encontramos ahora con el dilema de que ahora tenemos un miembro menos...y nos planteamos trasladar el proyecto a uno de tipado débil por comodidad?
Creo que me he explicado un poco mal, y me he dejado algunas cosas atrás.
#56DarkSoldier:#54 o sea que los tipos solo son para cuando trabajas en equipo grande no? madre de dios
Por supuesto que no. Las herramientas que te da para el IDE también están bien, de hecho muchos le encontrarán la gracia a eso, aunque yo la verdad que ya hace tiempo que me acostumbré a juguetear con JS sin mucha ayuda del navegador. Pero hay que admitir que es una comodidad muy difícil de lograr sin tipados estáticos.
#57 Si comienzas un proyecto usado tipado estático, por qué dejar de usarlo? Es lo mismo que si empiezas un proyecto sin usarlo, que tampoco tendrá sentido empezar a hacerlo. Yo creo que el que quiera permitirse usar ES6 en todo su potencial, arrays de tipo dinámico (sin necesidad de usar el puto <any>), usar objetos mutables, cambiar el prototipado de algún que otro objeto... y por supuesto, programar más rápido, no querrá usar TS.
Mi referencia a los grupos de trabajo era que una de las ventajas de TS es que la legibilidad del código es mayor, y queráis que no, esto es algo muy bueno en equipos de trabajo (más que nada uno grande).
Amplío con una entrada interesante de uno de los gurús de JS, Eric Elliot, hablando de muchas más ventajas y problemas relativos a TS: https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b#.w66w8es78
#54 Me gustaría conocer tu opinión en el por qué la documentación deja mucho que desear. Lo digo honestamente.
Entiendo lo de Typescript, es lo que se recomienda y todos los recursos se destinan a hacer de Typescript la mejor plataforma de Angular 2.
Por supuesto que se puede usar ES5 o ES6, pero el tipado de Typescript está muy bien.
Yo era muy muy reacio a Typescript, pero desde que estoy acostumbrado a el, hacer Javascript normal me sabe raro.
#58 es que flipo un poco con tu razonamiento, tu ya tienes un proceso de compilación ya que dices que usas es6, entonces, lo único que te molesta son los tipos? y tu vienes de Java?
https://www.reaktor.com/blog/refactoring-30000-lines-js-types/
