Una cosa ( bueno dos ) con un proyecto como este ( un proyecto que puede crecer y después se rehusado, que se yo ) usa siempre inglés, es mucho más fácil darle seguimiento a un código que está todo en inglés que a uno que esta en español ( o en spanglish ) , por la simple y sencilla razón que un potencial colaborador... chino, o hindú ( ya ves que casi no hay ) solamente va a entender inglés y además es el idioma defacto de la programación.
Entonces tu método sería : o todo en español Per executarQuery pues como que no.
Segunda: En java por conveción las clases empiezan con mayúsculas, por lo que debería de ser
Respondiendo a tu pregunta:
Yo lo usuría para hacer consultas en memoria. Me parece que tiene potencial para que se cargue un montón de datos desde algún lugar ( quizá otra base de datos ) y dentro del programa se hagan consultas
Por ultimo, existe una razón por la cual es una interfaz y no una clase, averiguala.
Submitted by YoSoyMamon on Vie, 04/16/2010 - 09:52.
Fijate Oscar que haces buenas observaciones en el post, sobretodo que por "Convencion" una clase se escribe con mayusculas, efectivamente asi como en la programacion, en el español tambien hay acuerdos
Yo lo usuría para hacer consultas
La palabra usuría No EXISTE en el español asi que por "convención" se escribe Usaría al igual que
después se rehusado
es "Ser", asi que primero antes de programar aprende a hablar y escribir en español...
Y otra cosa mas, la palabra "defacto" tampoco existe en el español, existe la locución "De Facto" que significa "De Hecho" asi que, de verdad primero ponte a estudiar español... porque tambien se te va el Spanglish...
Y Klone tu articulo me parece muy interesante. Felicidades no te deprimas por comentarios sin ningun sentido...
Por que habría de deprimirse, al contrario, debería de sentirse halagado.
Si hago la observación acerca del inglés es por que le veo potencial al proyecto. No tiene que ser inglés perfecto, simplemente lo básico para permitir que otros colaboren.
Toma cualquier proyecto que sea más o menos relevante ( en Java o en cualquier otro lenguaje ) y verás que todo está escrito en inglés.
Así que el comentario tiene muchísimo más sentido que el tuyo corrigiéndome conveción, usuría, se ( en vez de ser ) y defacto ( nomás 4? mmhhta, yo encontré al menos otros 4 errores más en mi propio post de los que mencionas y no menos de 8 en el tuyo, aunque tan irrelevantes como el contenido, bueno, la verdad la verdad, los encontró el spellchecker de firefox :P )
En fin estoy seguro que Carlos puede aprovechar perfectamente lo que haya de bueno en los comentarios que le hacemos y desechar el resto.
Como bien dice Jali, esto es una "comunidad" y como tal hay reglas para que esto no sea un desmadre.
Una de esas reglas es la siguiente:
Sé cortés y respetuoso en tus respuestas, recuerda que todos comenzamos desde cero y si no crees tener paciencia para responder algo, es mejor que no lo hagas.
Tómalo en cuenta YoSoyMamon, es tu primera aportación y pasa por esta ocasión, si quieres unirte a la comunidad eres bienvenido, pero las reglas siguen siendo claras para todos.
Me parece que la idea es buena, sin embargo creo que estás reinventando el hilo negro… quien no conoce la historia está condenado a repetirla, y en este caso estás repitiendo errores que ya se han cometido en otras plataformas (me viene a la mente PHP). Para usar tu base de datos hay que aprender un nuevo lenguaje que tú inventaste, cuando pudiste haberte basado en alguno existente para problemas similares (por ejemplo SQL, HQL o Rel). No necesitas implementar TODO el lenguaje, pero usar un subconjunto del mismo suaviza la curva de aprendizaje; incluso podrías haber tomado una ruta distinta como implementar una interfaz JDBC para tu base de datos. Pero si la funcionalidad es tan distinta que no permite el uso de algún lenguaje existente para queries, entonces lo mejor sería definir un API puramente programático, para no tener que hacer un parser y que luego cuando sofistiques más tu lenguaje vengan problemas similares a inyección de SQL.
Finalmente, como ya mencionaron, Serializable es una interfaz y no una clase por una razón muy importante; no sé si los objetos que se metan a tu base de datos deban forzosamente hereda de ObjetoSerializado o si pueden simplemente implementar Serializable y heredar de alguna otra cosa.
La idea es buena pero de todas formas échale un ojo a soluciones como Neo4J y Cassandra, que son almacenes de datos basados en llave, similares a lo que estás implementando.
el reinventar.. amm muy criticado hoy dia.. personalmente las frases "no reinventes la rueta" o "no reinventes el hilo negro".... son frases que de alguna manera son frases que siento en lo personal frustran y castran la creatividad y la innovación, tal vez la idea se parece o el concepto sea el mismo que uno que de igual forma desconoces o conscientemente dices esta esto pero quiero ver si lo puedo hacer mejor. ejemplo una libreria muy exitosa; jQuery trae un interprete de consulta para manipular DOM en js, pero que tontos estos chavos si ya estaban implementadas las librerías de DOM en JS ya se podían recuperar elements y trocitos de DOM, ya podía crear elementos, y con unos setInterval y una función podemos hacer animaciones .. aunque la verdad lo que mas me me gusta de esta pequeña libreria es el modo de recuperar trozos de DOM, mas que animaciones plugin y de mas. si nos vamos a ese par de frase todo lo que no fue primero es una gran tonteria.. los sistemas que nacieron despues del primer S.O. son una tonteria... Linus para que hacia el kernel de Linux si ya teníamos Unix.. y muchos otros ejemplos que puedo dar.
tal vez la observación es valida si tubieramos la prisa de vender algo y crear algo industrial.. pero cuando son proyecto de hobbie de querer inventar algo, tal vez este creando algo nuevo algo que a el solo le servirá para aprender. tal vez de allí salga algo que servirá a la humanidad completa, creo que tratar de crear algo nunca será una tontería como las frases dichas lo pretenden dar a entender(o por lo menos eso es lo que me molesta de dichas frases y lo que yo entiendo de ellas), ¿para que crear el foco si ya existían las velas?, entonces el mismo Java es una tontería.. ya que no fue el primer lenguaje inventado ¿para que hacer otro si ya existían no uno si no varios?
Al momento que habían publicado este artículo, no se especificaba si hablaba de un software que solamente se hizo para ilustrar un punto, si era una prueba de concepto, o un ejercicio que se hizo para la universidad, o era parte de un sistema en producción. Por eso puse creo que estás reinventando el hilo negro. Ya con el comentario que agregaron recientemente a este artículo puedo ver que es un proyecto real, no es un simple ejercicio, y que lo publicaron como software libre bajo la licencia GPL, lo cual me parece una excelente idea, ya que así cualquiera de nosotros puede revisar el código y contactar al autor para sugerir mejoras, correcciones, o incluso unirse al proyecto y contribuir de manera más directa.
No es malo reinventar cosas existentes en todos los ámbitos. Algunos de los ejemplos no son reinvenciones de hecho. El foco no es una reinvención de la vela; Java fue inventado para tener un lenguaje orientado a objetos con una máquina virtual que permitiera hacer aplicaciones portables, que corrieran en cualquier sistema operativo (o de hecho en cualquier dispositivo) que tuviera una JVM. Torvalds hizo Linux al principio como un ejercicio porque en Finlandia no hay mucho que hacer en invierno y si iba a tener la compu prendida para darse calor, pues por qué no hacer un kernel de una vez? Jejej no pero realmente aunque comenzó como un hobby, lo que hizo que cobrara tanta popularidad fue pegarle la licencia GPL; hasta ese momento no había un solo kernel de sistema operativo de software libre.
Hay software que sus versiones posteriores son creadas nuevamente desde cero, porque los cambios a su API, funcionalidad, etc son tan radicales que es mejor hacerlo nuevamente en vez de modificar el software existente. Pero el principio DRY (Don't Repeat Yourself) se enfoca a que no hagas cosas desde cero si ya existe el software que resuelva ese mismo problema. En este caso concreto, suponiendo que sea un software que se usa para sistemas en producción... una cosa es tener una aplicación que resuelve un problema específico para un cliente (o para uno mismo) y otra cosa es hacer software de infraestructura específico para dicha aplicación. Qué es software de infraestructura? Pues un sistema operativo, un servidor de base de datos, un servidor web, un contenedor de aplicaciones JEE, un sistema para manejo de archivos... ese tipo de cosas solamente hay que hacerlas si de plano ninguna de las opciones existentes nos sirve como está y no se puede modificar (por la razón que sea).
Por ejemplo la base de datos Cassandra, la creó Facebook y la liberó y se la pasó a la Apache Software Foundation. Por qué la hicieron, si pudieron haber usado MySQL, PostgreSQL, Oracle, etc? Pues porque ya ninguno de esos servidores de base de datos les estaba sirviendo para lo que necesitaban, y decidieron que no había otra opción más que crear su propia base de datos, que fuera distribuida, que fuera muy rápida en respuestas aunque no mantuviera la integridad de los datos (por eso la describen como eventually consistent), que fuera fácil de mantener y de escalar (solamente agregar más nodos al cluster), que fuera de bajo costo, etc. Pero no es un sustituto de una base de datos relacional.
Hola pues muchas gracias por las sugerencias de todos he estado tomando en cuenta sus opiniones y de antemano muchas gracias me han hecho investigar algunas cosas que ni por la mente me pasaban pero bueno les aviso que ya tiene nombre el proyecto y lo apode LilaDB
Un aporte interesante. Simplemente hay que tomar en cuenta algunos aspectos de redacción ya que la idea principal se ve opacada. Además concuerdo con lo que escribe mi compañero ezamudio.
Muy interesante.
Muy interesante.
Una cosa ( bueno dos ) con un proyecto como este ( un proyecto que puede crecer y después se rehusado, que se yo ) usa siempre inglés, es mucho más fácil darle seguimiento a un código que está todo en inglés que a uno que esta en español ( o en spanglish ) , por la simple y sencilla razón que un potencial colaborador... chino, o hindú ( ya ves que casi no hay ) solamente va a entender inglés y además es el idioma defacto de la programación.
Entonces tu método sería :
Segunda: En java por conveción las clases empiezan con mayúsculas, por lo queRespondiendo a tu pregunta:
Yo lo usuría para hacer consultas en memoria. Me parece que tiene potencial para que se cargue un montón de datos desde algún lugar ( quizá otra base de datos ) y dentro del programa se hagan consultas
Por ultimo, existe una razón por la cual
OscarRyz.... ya ni la ch!!
Fijate Oscar que haces buenas observaciones en el post, sobretodo que por "Convencion" una clase se escribe con mayusculas, efectivamente asi como en la programacion, en el español tambien hay acuerdos
La palabra usuría No EXISTE en el español asi que por "convención" se escribe Usaría al igual que
es "Ser", asi que primero antes de programar aprende a hablar y escribir en español...
Y otra cosa mas, la palabra "defacto" tampoco existe en el español, existe la locución "De Facto" que significa "De Hecho" asi que, de verdad primero ponte a estudiar español... porque tambien se te va el Spanglish...
Y Klone tu articulo me parece muy interesante. Felicidades no te deprimas por comentarios sin ningun sentido...
YoSoyMasMamón
¿Qué te pasa YoSoyMamon?.
Apoco nomas entras pa tirar mierda? Esto es una comunidad y estamos para echarnos la mano.
"Convencion" lleva acento por lo que yo usaría "Convención" y "Programación" también, asi que no mames chavo jajaja.
Aparte de mamón, mediocre.
Saludos
@PuesSiQueLoEres
Por que habría de deprimirse, al contrario, debería de sentirse halagado.
Si hago la observación acerca del inglés es por que le veo potencial al proyecto. No tiene que ser inglés perfecto, simplemente lo básico para permitir que otros colaboren.
Toma cualquier proyecto que sea más o menos relevante ( en Java o en cualquier otro lenguaje ) y verás que todo está escrito en inglés.
Así que el comentario tiene muchísimo más sentido que el tuyo corrigiéndome conveción, usuría, se ( en vez de ser ) y defacto ( nomás 4? mmhhta, yo encontré al menos otros 4 errores más en mi propio post de los que mencionas y no menos de 8 en el tuyo, aunque tan irrelevantes como el contenido, bueno, la verdad la verdad, los encontró el spellchecker de firefox :P )
En fin estoy seguro que Carlos puede aprovechar perfectamente lo que haya de bueno en los comentarios que le hacemos y desechar el resto.
Lineamientos
Como bien dice Jali, esto es una "comunidad" y como tal hay reglas para que esto no sea un desmadre.
Una de esas reglas es la siguiente:
Tómalo en cuenta YoSoyMamon, es tu primera aportación y pasa por esta ocasión, si quieres unirte a la comunidad eres bienvenido, pero las reglas siguen siendo claras para todos.
¡Muy buen aporte Klone!
Saludos.
Javier Ramírez Jr.
Por supuesto..
que parece interesante... a mi me gusto la idea... :)
PCJ
Me parece que la idea es buena, sin embargo creo que estás reinventando el hilo negro… quien no conoce la historia está condenado a repetirla, y en este caso estás repitiendo errores que ya se han cometido en otras plataformas (me viene a la mente PHP). Para usar tu base de datos hay que aprender un nuevo lenguaje que tú inventaste, cuando pudiste haberte basado en alguno existente para problemas similares (por ejemplo SQL, HQL o Rel). No necesitas implementar TODO el lenguaje, pero usar un subconjunto del mismo suaviza la curva de aprendizaje; incluso podrías haber tomado una ruta distinta como implementar una interfaz JDBC para tu base de datos. Pero si la funcionalidad es tan distinta que no permite el uso de algún lenguaje existente para queries, entonces lo mejor sería definir un API puramente programático, para no tener que hacer un parser y que luego cuando sofistiques más tu lenguaje vengan problemas similares a inyección de SQL.
Finalmente, como ya mencionaron, Serializable es una interfaz y no una clase por una razón muy importante; no sé si los objetos que se metan a tu base de datos deban forzosamente hereda de ObjetoSerializado o si pueden simplemente implementar Serializable y heredar de alguna otra cosa.
La idea es buena pero de todas formas échale un ojo a soluciones como Neo4J y Cassandra, que son almacenes de datos basados en llave, similares a lo que estás implementando.
reinventando el hilo negro
el reinventar.. amm muy criticado hoy dia.. personalmente las frases "no reinventes la rueta" o "no reinventes el hilo negro".... son frases que de alguna manera son frases que siento en lo personal frustran y castran la creatividad y la innovación, tal vez la idea se parece o el concepto sea el mismo que uno que de igual forma desconoces o conscientemente dices esta esto pero quiero ver si lo puedo hacer mejor. ejemplo una libreria muy exitosa; jQuery trae un interprete de consulta para manipular DOM en js, pero que tontos estos chavos si ya estaban implementadas las librerías de DOM en JS ya se podían recuperar elements y trocitos de DOM, ya podía crear elementos, y con unos setInterval y una función podemos hacer animaciones .. aunque la verdad lo que mas me me gusta de esta pequeña libreria es el modo de recuperar trozos de DOM, mas que animaciones plugin y de mas. si nos vamos a ese par de frase todo lo que no fue primero es una gran tonteria.. los sistemas que nacieron despues del primer S.O. son una tonteria... Linus para que hacia el kernel de Linux si ya teníamos Unix.. y muchos otros ejemplos que puedo dar.
tal vez la observación es valida si tubieramos la prisa de vender algo y crear algo industrial.. pero cuando son proyecto de hobbie de querer inventar algo, tal vez este creando algo nuevo algo que a el solo le servirá para aprender. tal vez de allí salga algo que servirá a la humanidad completa, creo que tratar de crear algo nunca será una tontería como las frases dichas lo pretenden dar a entender(o por lo menos eso es lo que me molesta de dichas frases y lo que yo entiendo de ellas), ¿para que crear el foco si ya existían las velas?, entonces el mismo Java es una tontería.. ya que no fue el primer lenguaje inventado ¿para que hacer otro si ya existían no uno si no varios?
Contexto
Al momento que habían publicado este artículo, no se especificaba si hablaba de un software que solamente se hizo para ilustrar un punto, si era una prueba de concepto, o un ejercicio que se hizo para la universidad, o era parte de un sistema en producción. Por eso puse creo que estás reinventando el hilo negro. Ya con el comentario que agregaron recientemente a este artículo puedo ver que es un proyecto real, no es un simple ejercicio, y que lo publicaron como software libre bajo la licencia GPL, lo cual me parece una excelente idea, ya que así cualquiera de nosotros puede revisar el código y contactar al autor para sugerir mejoras, correcciones, o incluso unirse al proyecto y contribuir de manera más directa.
No es malo reinventar cosas existentes en todos los ámbitos. Algunos de los ejemplos no son reinvenciones de hecho. El foco no es una reinvención de la vela; Java fue inventado para tener un lenguaje orientado a objetos con una máquina virtual que permitiera hacer aplicaciones portables, que corrieran en cualquier sistema operativo (o de hecho en cualquier dispositivo) que tuviera una JVM. Torvalds hizo Linux al principio como un ejercicio porque en Finlandia no hay mucho que hacer en invierno y si iba a tener la compu prendida para darse calor, pues por qué no hacer un kernel de una vez? Jejej no pero realmente aunque comenzó como un hobby, lo que hizo que cobrara tanta popularidad fue pegarle la licencia GPL; hasta ese momento no había un solo kernel de sistema operativo de software libre.
Hay software que sus versiones posteriores son creadas nuevamente desde cero, porque los cambios a su API, funcionalidad, etc son tan radicales que es mejor hacerlo nuevamente en vez de modificar el software existente. Pero el principio DRY (Don't Repeat Yourself) se enfoca a que no hagas cosas desde cero si ya existe el software que resuelva ese mismo problema. En este caso concreto, suponiendo que sea un software que se usa para sistemas en producción... una cosa es tener una aplicación que resuelve un problema específico para un cliente (o para uno mismo) y otra cosa es hacer software de infraestructura específico para dicha aplicación. Qué es software de infraestructura? Pues un sistema operativo, un servidor de base de datos, un servidor web, un contenedor de aplicaciones JEE, un sistema para manejo de archivos... ese tipo de cosas solamente hay que hacerlas si de plano ninguna de las opciones existentes nos sirve como está y no se puede modificar (por la razón que sea).
Por ejemplo la base de datos Cassandra, la creó Facebook y la liberó y se la pasó a la Apache Software Foundation. Por qué la hicieron, si pudieron haber usado MySQL, PostgreSQL, Oracle, etc? Pues porque ya ninguno de esos servidores de base de datos les estaba sirviendo para lo que necesitaban, y decidieron que no había otra opción más que crear su propia base de datos, que fuera distribuida, que fuera muy rápida en respuestas aunque no mantuviera la integridad de los datos (por eso la describen como eventually consistent), que fuera fácil de mantener y de escalar (solamente agregar más nodos al cluster), que fuera de bajo costo, etc. Pero no es un sustituto de una base de datos relacional.
Ya tiene nombre! -LilaDB-
Hola pues muchas gracias por las sugerencias de todos he estado tomando en cuenta sus opiniones y de antemano muchas gracias me han hecho investigar algunas cosas que ni por la mente me pasaban pero bueno les aviso que ya tiene nombre el proyecto y lo apode LilaDB
Revisado PCJ
Un aporte interesante. Simplemente hay que tomar en cuenta algunos aspectos de redacción ya que la idea principal se ve opacada. Además concuerdo con lo que escribe mi compañero ezamudio.
Lo lamento soy pesimo
Lo lamento soy pesimo redactando X_X como diria mi abuelita
"Pero me entendistes no?"
jajajajaj saludos