Staging ::: VER CORREOS
Acceder

Participaciones del usuario bacterio77

bacterio77 08/03/23 19:18
Ha respondido al tema MongoDB
 Y AHORA SÍ, HABLAMOS DE MongoDB…  Las bases de datos diseñadas por MongoDB tienen, desde sus cimientos, un formato diferente a las de las bases de datos relacionales (o bases de datos basadas en tablas y SQL). Utiliza un sistema de almacenaje de información diferente, llamado BSON (binary JSON), que a su vez procede del JSON (JavaScript Object Notation). Realmente no tengo experiencia con BSON, aunque sí un poco con JSON, pero para hacernos una idea, puede servir. La forma de almacenar datos en JSON y BSON es muy parecida a la forma en la que realizaríamos, por ejemplo, al hacer un esquema-resumen de unos apuntes de clase. La información es organizada de una forma jerárquica: se crean puntos o elementos de una lista, y cada uno de esos puntos puede a su vez subdividirse libremente en el número de puntos que sea necesario. Además, ya no tenemos la rigidez de formato de las tablas de las bases de datos tradicionales y, según sea necesario, cada nivel del esquema puede almacenar tipos de datos muy diferentes. Volviendo al ejemplo de antes de la librería, la información de los clientes tendría una estructura como la que sigue:  Cliente: Fulano Fulanez (Dirección, datos contacto, etc…)                 Compra: El conde de Mostecristo (ISBN, editorial, precio, etc)                 Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc)                 Compra: La legión maldita Cliente: John Doe (Dirección, datos contacto, etc…)                 Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc)                 Compra: Python avanzado (ISBN, editorial, precio, etc) Cliente:  Pedro Falso (Dirección, datos contacto, etc…)                 Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc)  Este formato de almacenaje de datos es más flexible a la hora de incorporar nueva información, incluso de datos que en principio no estuvieran previstos. Imaginemos que hemos creado una web de nuestra librería y queremos añadir las valoraciones que hacen los clientes: bastaría añadirlos a la misma lista, con lo que seguimos teniendo un rápido acceso a la información. Si hubiéramos usado bases de datos relacionales / SQL, habríamos tenido que crear nuevas tablas, nuevas relaciones, y aumentar la complejidad del sistema para cuando planeáramos realizar búsquedas de esta nueva información. Lo anterior quedaría como (cambios en negrita):  Cliente: Fulano Fulanez (Dirección, datos contacto, etc…)                 Compra: El conde de Mostecristo (ISBN, editorial, precio, etc)                 Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc)                 Compra: La legión maldita                 Valoración: Acerca de: “El conde de Montecristo”, Comentario: “Clásico de imprescindible lectura”.                 Valoración: Acerca de: “Mis años con Carmele”, Comentario: “No lo recomiendo”. Cliente: John Doe (Dirección, datos contacto, etc…)                 Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc)                 Compra: Python avanzado (ISBN, editorial, precio, etc) Cliente:  Pedro Falso (Dirección, datos contacto, etc…)                 Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc)  Una alternativa sería, si así lo decidiera el diseñador de la web, limitar los comentarios a aquellos libros que el cliente haya comprado en la web, y hacer que aparecieran referidos a la compra correspondiente:  Cliente: Fulano Fulanez (Dirección, datos contacto, etc…)                 Compra: El conde de Mostecristo (ISBN, editorial, precio, etc)                                 Valoración: Comentario: “Clásico de imprescindible lectura”.                 Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc)                 Compra: La legión maldita Cliente: John Doe (Dirección, datos contacto, etc…)                 Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc)                 Compra: Python avanzado (ISBN, editorial, precio, etc) Cliente:  Pedro Falso (Dirección, datos contacto, etc…)                 Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc)  A la hora de acceder a la información, esto supone que va a ser más fácil para el motor de la base de datos: la información que necesitamos está ordenada de una forma sencilla. 
bacterio77 08/03/23 19:17
Ha respondido al tema MongoDB
EXTENSION ACTUAL DEL USO DE BASES DE DATOS EN LA WEBComo hemos visto, esa base de datos de nuestro ejemplo, que inicialmente empezó en una pequeña cadena de tiendas físicas, se puede modificar para albergar información de los usuarios, como comentarios, valoraciones, etc y dar el salto a una plataforma de ventas web.Pero esto se puede utilizar también para todo tipo de diseños web.Para quien haya creado una pequeña web estática (es decir, que no use bases de datos), sabrá que en realidad se trata de un conjunto de páginas, hasta cierto punto parecidas a un documento de Word, interconectadas por hipervínculos. Estas páginas se suben al servidor, pero también podrían usarse desde una carpeta de un pc y se podría navegar entre ellas de forma similar. Todas las páginas web han sido creadas explícitamente por una persona y se localizan en el servidor. Pero en realidad esto no es lo habitual.En la mayoría de webs comerciales, con cantidades de productos y otros tipos de  información que se actualiza constantemente (pongamos el ejemplo de Amazon, para seguir con las “librerías”) el funcionamiento es distinto. Cuando entramos en la descripción de un producto, donde nos aparecen las valoraciones, especificaciones, foto, precio, vinculo al carro de la compra…. En realidad se trata de una plantilla que accede a una base de datos en un servidor y utiliza la información que extrae de ésta para reconstruir la página web.En realidad, podemos ir más allá del comercio electrónico y pensar en cualquier red social, como por ejemplo la misma Rankia. Cuando escribimos un post como este, no se está generando una página nueva, sino que guardando información en una base de datos. Cuando se actualiza la página de los foros, se recurre a una base de datos para regenerar la página con los últimos hilos en los que se ha escrito.En realidad, prácticamente cualquier servicio basado en la web va a requerir este tipo de tecnología. COMPLEJIDAD Y ESCALABILIDAD LIMITADA DE BASES DE DATOS TRADICIONALESEste apartado es importante para entender una de las ventajas de MongoDB, la ESCALABILIDAD de las bases de datos.Según el tamaño y complejidad de la base de datos, aumenta la cantidad de trabajo que el ordenador (o más concretamente el servidor) tiene que realizar.Y aquí volvemos al principio: tenemos instalado un programa de gestión en nuestro PC, o en nuestro móvil, que accede a la nube, donde hay una base de datos de la que extrae información.  ¿Pero dónde está, físicamente, esa base de datos?. En un servidor o unos pocos servidores. Ahí tenemos un problema, puesto que el numero de servidores no puede ser infinito: en una red grande (pensemos de nuevo en Amazon o Facebook) hay muchos usuarios accediendo al mismo tiempo a los datos, modificando esta información, haciendo compras, escribiendo comentarios, valorando (puntuando) esos productos… El archivo que contiene todos estos datos se va actualizando en tiempo real, y si hay muchos servidores con copias de ese archivo, los cambios que se hacen en uno deben trasladar a los demás de una forma rápida para evitar inconsistencias en la información de la web.Supongamos por ejemplo que en una gran red social se crea una funcionalidad que permite ver todos los “me gusta” que ha indicado un usuario. Existiría una enorme tabla de “me gustas”, en los que cada “me gusta” escrito por cada usuario aparecería como un registro independiente. Cada registro tendría, al menos, además del identificador propio del registro, un campo con el identificador del comentario al que se refiere y otro campo con un identificador del usuario. Imaginad el enorme tamaño de una tabla como esta. Pues bien, si entramos en nuestro usuario y revisamos nuestros “me gusta”, estamos obligando al servidor a buscar en esa enorme tabla todos y cada uno de los registros en los que aparece nuestro identificador. Aunque la capacidad de procesamiento de los ordenadores actuales permite realizar la búsqueda relativamente pronto, teniendo en cuenta que ese servidor tiene que dar servicio a muchos usuarios, es fácil imaginar la sobrecarga que este tipo de procesos.Además, según como esté organizada la base de datos, ciertos tipos de búsquedas pueden ser bastante complicadas: por ejemplo, podríamos tener que acceder a un usuario y cruzar su id con una tabla en la que aparezcan todos los comentarios escritos en esa web y tener que separar aquellos hechos por este usuario, y cruzar con una tercera tabla para ver las valoraciones que han hecho otros usuarios de ese comentario… y el proceso se podría hacer tan complejo como se quiera imaginar.Concluyo este apartado con una matización que quizás se salga del tema principal, porque muchos preferirán saltar hasta el siguiente apartado.En realidad, existe algún truco para agilizar este tipo de búsquedas, que consistiría en guardar información redundante, pero que nos permitiría reducir el número de búsquedas realizadas por el servidor. Por ejemplo, para la forma teóricamente idónea para saber cuantos me gusta ha recibido uno de nuestros estados en Facebook sería que el servidor buscara el código interno de ese estado y lo usara para, en esa tabla enorme de “me gustas”, contara cuantos hay referidos a ese estado. Pero una alternativa sería que en la tabla donde se almacena la información del estado se añadiera un campo que indicara el número de “Me gustas”, y cada vez que un usuario hiciera click, se incrementara en 1. Solo en el caso de que alguien quisiera comprobar a quien le ha gustado el comentario sería necesario recurrir a la otra tabla. Pero eso, en teoría, violaría uno de los principios ideales de las bases de datos relacionales, la normalización, que viene a decir que la información no debería aparecer de forma redundante (duplicada).Desde el punto de vista teórico, la normalización puede estar bien, pero en la práctica, conforme aumenta el tamaño (numero de registros por tabla) y la complejidad (número de tablas relacionadas) de nuestra base de datos, aumenta ingentemente el consumo de recursos que el servidor dedica a las búsquedas. Sin embargo, el hecho de tener que realizar este tipo de “arreglos” (saltarse las reglas de “normalización”) para mejorar el rendimiento ya indica que el modelo original empieza a tener problemas.
bacterio77 08/03/23 19:16
Ha publicado el tema MongoDB
bacterio77 02/03/23 18:04
Ha respondido al tema Valores conservadores/ largo plazo
Buenas tardes a todos.Como en su momento hablé en este hilo de que había abierto cuenta en Interactive Brokers, y si miras en distintos foros parece que es el mejor broker del mundo, aprovecho para compartir este enlace en el que comento mis malas experiencias con ellos, por si a alguien le puede servir de ayuda...www.rankia.com/foros/bolsa/temas/4643787-atencion-cliente-interactive-brokers?page=2#respuesta_5757192
bacterio77 02/03/23 18:01
Ha respondido al tema Atención al cliente Interactive Brokers
Buenos días a todos.Hace poco más de un año abrí cuenta con Interactive Brokers aprovechando que habían eliminado la comisión de mantenimiento. La verdad es que tenía muy buenas expectativas con el broker y había empezado a operar con él, en principio sin problemas porque no suelo requerir asistencia técnica.El problema es cuando decido realizar un traspaso de acciones desde mi otro broker de unas acciones canadienses (sencillamente porque según tenía entendido, IB tramita el equivalente al W8BEN para otros países con tratado de doble imposición con españa). Tras más de 3 semanas sin que se produzca el traspaso, comunico con IB. Mi experiencia a partir de ahí se asemeja a las de muchos otros usuarios del foro:- escribo un ticket en el centro de mensajes de ayuda del que, tras 3 días hábiles, no respondo ningún tipo de respuesta.- escribo en el chat de atención al cliente, en el que al principio me desconectan y en un segundo intento, tras más de 10 minutos de espera, me vienen a decir que el ticket se va a responder en breve y que no haga más tickets. Por supuesto, al día siguiente sigo sin tener noticia.En fin, contactando con mi otro broker, al que ya en su momento envié el correspondiente formulario con la autorización del traspaso, me responden casi de inmediato que están  a la espera de recibir instrucciones para el traspaso por parte de IB y que no la han recibido.En definitiva, tras todo lo anterior he decidido cancelar la trasferencia (prefiero pagar la doble imposición pero tener las acciones en un broker más fiable) y mantendré la cuenta de IB solo para las acciones que ya tenía compradas allí. Respecto a la doble imposición de dividendos, sencillamente evitaré invertir en países con este tipo de problemas. En fin, en varios foros de internet dará la impresión de que IB es la panacea y el mejor broker del mundo, pero si hubiera conocido este hilo antes no me habría tomado la molestia de trabajar con ellos.
bacterio77 25/02/23 10:57
Ha respondido al tema ¿Cómo recuperar las retenciones de dividendos de empresas alemanas?
Cuando yo lleve los modelos a hacienda, el funcionario que me atendió me dijo inicialmente eso y que solo se sellanan documentos extranjeros en unos pocos casos concretos, pero despues miro su ordenador donde al parecer vio que ese era uno de los casos y donde al parecer explicaba el procedimiento y al final me los selló.Estoy hablando de la oficina de hacienda en Murcia, no en la sede central nacional, asi que deberian poder hacerlo en cualquier sede. 
bacterio77 23/02/23 17:21
Ha respondido al tema Pulso de Mercado: Intradía
Segunda oleada inflacionista?. No sabía que hubiera remitido la primera…
bacterio77 20/02/23 18:01
Ha respondido al tema Valores conservadores/ largo plazo
Este miércoles presenta resultados Fresenius SE.Los últimos no fueron malos, pero no me acabaron de gustar. Siguen teniendo un nivel alto de deuda neta; me gusta considerar la deuda neta respecto al beneficio neto, lo que representaría el tiempo que tardaría en pagar la deuda si empleara todo lo que ganaran en esto. Si consideramos el beneficio neto del ultimo trimestre anualizado, o el BN de los últimos trimestres, este ratio estaría, respectivamente, en 10 ó 12 años (10-12x).La empresa ha ido aumentando ingresos trimestre tras trimestre, lo que en principio es buenisimo, pero ha reducido su margen de beneficio neto y esto ha hecho que el beneficio neto, por contra, se mantenga plano o tienda incluso a reducirse.Ingresos (azul), BN (negro) y deuda neta (verde)Si la empresa sube los precios en paralelo a la inflación, manteniendo márgenes, lo hará bien.Pero si no lo consigue y, peor aun, si el beneficio neto sigue reduciéndose, este ratio se hará más elevado, y quizás tendrá que empezar a hacer desinversiones y otras cosas de las que acaban por reducir el valor de una empresa.Ahora vemos los tipos de interés del BCE 2% y nos parecen una barbaridad, pero ya se está hablando de subirlos al 3.7%. Históricamente, en periodos de inflación elevada, han llegado a ser mayores del 10% (años 80). Dudo que en esta ocasión vayan a subirlos tanto, porque los países serían incapaces de pagar su deuda soberana, pero no tengo claro que se vaya a detener en un 3.7%, que ya es de por sí alto para lo que hemos visto en los últimos 20 años. Y si pienso así, eso significa que hay que quitarse a las empresas con deuda. Por lo pronto ya han quitado el dividendo real y lo han sustituido por dividendo scrip, cosa que en España ya sabemos a lo que conduce (dilución de las acciones)-De esta empresa me gustaba sobre todo la parte de clínicas privadas, como el grupo Helios (Quirón en España), pero ya anunciaron que es la parte del negocio de la que primero se van a deshacer.En fin, quería vender la mitad hoy y esperar a resultados para decidir si vendía el resto, pero me he sentido tan aliviado vendiendo la primera mitad que al final he vendido también el resto. La empresa sube un 45% desde mínimos, pero no voy a vender, yo las tenía de hace tiempo y cierro en negativo (otra vez). Por suerte, casi todas las tecnológicas este año lo están haciendo muy bien (Sansung, LAM, AMAT, mi chicharril NVE... todas menos Intel). Pero veo que se avecinan tiempos difíciles con respecto a la deuda y creo que es mejor hacer poda de las empresas que me puedan dar sustos aunque venda en pérdidas con ellas, cortar las malas hierbas y regar las buenas, y no hacer lo contrario que siempre acaba siendo una operación ruinosa.A ver como salen los resultados... siempre que tomo una decisión de este tipo, el corto plazo acaba quitándome la razón, así que no me extrañaría que los resultados fueran buenos y acabe lamentando no haberme quedado con la mitad...
bacterio77 14/02/23 17:32
Ha respondido al tema Valores conservadores/ largo plazo
A consecuencia de lo que hablamos ayer de la composición del accionariado (ayer lo mencioné con Masimo), he estado curioseando y he caíodo en la cuenta de que Vanguard tiene el 8-12% de casi todas las empresas del SP500. Y Vanguard no es la unica gestora que compra indexados.Ya había oído que los indexados tenían gran parte del capital de las empresas de los indices, pero nunca se me había ocurrido consultar el dato. Desde luego, que esto tiene peso en los movimientos de las acciones...
bacterio77 14/02/23 17:19
Ha respondido al tema Valores conservadores/ largo plazo
Muy buenos criterios, pero me parece que ni siquiera Google cumple todas esas características...Y si te parece que el mundo de los semis es complicado, las farmaceúticas es todavía peor : puede salir un fármaco con muy buenos resultados pero después resulta que aparece una reacción idiosincrásica que produce hepatitis fulminante en uno de cada 1000 pacientes y lo retiran de comercialización; hay que estar pendiente de las patentes; para cuando sale un fármaco prometedor, resulta que a los 6 meses sale un competidor del mismo grupo farmacológico fabricado por la competencia.Ojo que yo también llevo farmas, pero para que su comportamiento sea más predecible es necesario que sean empresas grandes, con una gran cartera de productos, de forma que no sea necesario llevar la cuenta de cuando caduca cada patente ni del éxito o fracaso de cada uno de sus fármacos, sino que en conjunto se compensen (igual que sucede con una cartera de valores bien diversificada).Y esto es una opinión personal: merece la pena que tenga muchos productos biológicos o nuevos tipos de fármacos, como los anticuerpos humanizados y los ARN mensajeros (por ej: Amgen, Regeneron, Roche y con respecto los ARN, Pfizer, que son las que llevo).