Reprise du message précédent :

 
GG GROS
Tu peux redonner le modèle de ta fraiseuse ?
 
Le fablab que je fréquente va acheter une CNC (budget prévu environ 8000€).
Est-ce que tu as des conseils de modèles ? marques ?
 
C'est pour fraiser du bois / métal / carbone (sous eau) / POM / ...
 

Les cabanes étaient pil-poil sur la trajectoire
 
Mais bon, c'est pas une colline, c'est un massif, l'autre versant est derrière 5km de roche, à 6h de marche

C'est pas tout les jours qu'un avion se vautre... à Vautreuil

Je dois implémenter une système de prix évolutif (i.e: 10 euros le 1 juin, 20 euros le 1 juillet, etc...) comment vous implémenteriez ça avec une base PostgresSQL derrière?

Il y a des "trous" sur tes plages de dates, avec un prix par défaut au milieu, ou c'est continu ?

Et tu veux utiliser ça pour, en gros, quoi comme genre de requête ?

C'est continu, y'a le prix est effectif jusqu'a expiration, par extension le dernier prix reste jusqu'a que l'évenement soit fermé à l'achat.
C'est rattaché à un évenement ou à un forfait, comme le système super early bird, early bird, late bird, super late bird des conférences.

Je calculerais les valeurs côté Python et une ligne par date

J'ai pas forcément tous les éléments, mais là comme ça, pourquoi ne tout simplement pas faire une table de prix en ce cas, avec une date de début, une date de fin, la clef externe vers le truc auquel ça s'applique, et le prix ?
Comme ça t'es en 1-n, tu fais juste une jointure, et un where "applicationDate between startDate and endDate "

edit : ou alors les prix sont pas fixes mais calculés en fonction de formules ?

laisse tomber il te faut une vraie fraiseuse, moi techniquement c'est un routeur à commande numérique. La différence c'est que j'ai un portique qui se balade au-dessus d'une table. Une fraie fraiseuse, t'as une table qui bouge sous une colonne, et l'outil monte et descend le long de la colonne.
 
En gros pour le bois tu va être tenté d'avoir une fraiseuse aussi grande que possible pour essayer de mettre des plaques de contreplaqué, pour le métal, c'est toujours plus petit pour être plus rigide.
 
J'ai pas de recommandation, moi j'avais décidé de payer le moins cher possible, et donc j'ai pas étudié le marché en détail.
 
J'ai une CNC6040Z de ebay, en provenance directe de Chine à 1500€.

+1
 
Si ça se calcule et que tu veux la jouer warrior, tu fais une procedure stockeé qui te calcule ça. Mais à froid, et sans plus d'éléments, c'est pas ma solution favorite

Je t'écoute.

C'est la première idée que j'ai eu, mais je me suis demandé si y'avait pas moyen de dénormaliser un peu (prémature optimisation toussa), car j'ai 4 niveau de relations avant d'arriver au prix. Sinon pourrait peut-être le remonter periodiquement à minuit chaque jour.

 
tu fais une vue entre ta table de "produits" et ta table de prix telle qu'elmoricq te l'a indiqué ?  

 
C'est pas tant que ça.
En SGBD faut raisonner de manière ensembliste, l'optimiseur SGBD gère très bien ensuite si ton modèle est propre.
 
Si ton prix est rattaché directement à 1 ensemble avec une relation [1-N] propre avec une jolie contrainte FK, l'impact en performance devrait être négligeable.

Tu peux même faire une vue materialisée  que tu ne refresh qu'une fois de temps en temps si tu peux te le permettre (cf maj a minuit )

@elmo : tu as quand même une requete du genre :

SELECT 
    product.product_id, 
    price_ref.price 
FROM price_ref  
INNER JOIN product 
   ON  product.product_id= price_ref.product_id /*FK :, donc quasi gratuit */
         AND product.date BETWEEN price_ref.start AND price_ref.end /* pas FK , donc cout léger*/

Bon, j'ai opté pour la sécurité, j'ai finalement pris la GeForce, qui est en refroidissement passif, en plus.

Perso en PC, maintenant ce sont des NUC pour tous le monde
 
C'est vraiment parfait sur les bureaux

GitHub DDosé un jour de release pour nous

https://news.ycombinator.com/item?id=9275041

SELECT 
    product.product_id, 
    price_ref.price 
FROM price_ref  
INNER JOIN product 
   ON  product.product_id= price_ref.product_id /*FK :, donc quasi gratuit */
         AND product.date BETWEEN price_ref.start AND price_ref.end /* pas FK , donc cout léger*/

Oui, mais par essence la table price_ref est très petite par rapport à product, et puis les comparaisons de date ça va super vite

Maintenant je viens de zieuter rapidement parce que je connais pas postgreSQL, et visiblement on peut créer des ranges de dates :
http://www.postgresql.org/docs/cur [...] types.html

Je sais pas ce que ça vaut mais j'aime bien le concept et y a des chances que ça serve à shinuza pour son cas d'utilisation.

edit:  ça a l'air pénible à utiliser par contre

SELECT 
    product.product_id, 
    price_ref.price 
FROM price_ref  
INNER JOIN product 
   ON  product.product_id= price_ref.product_id /*FK :, donc quasi gratuit */
         AND product.date BETWEEN price_ref.start AND price_ref.end /* pas FK , donc cout léger*/

C'est rien, surtout que dans la table price_ref, il y a entre 1 et 10 lignes/produit à tout casser.

edit: crâmé par elmo

 
L'approche qu'Elmoricq a bcp mieux expliquée

J'ai oublié de mettre le smiley  
 
C'est sexy les range, mais je ne les ai jamais mises en pratique

 
On en parlait cette semaine justement    
 
Je vais regarder dans quelle mesure on peut avoir un miroir en interne.

un gitlab et zou

sinon, il y a des truc genre private-bower, mais ca te force aussi a trouver un private-npm, private-webpack,...
edit : le lien vers private bower https://github.com/Hacklone/private-bower

 
Et v'là le bordel le jour où tu veux changer de SGBD

Ouais on sait jamais tu pourrais passer à mongodb pour être webscale, alors faut éviter les trucs avancé genre les entiers ou les NOT NULL.

Puis en utilisant mal tes outils existants, t'as une bonne raison de changer d'outil pour un autre truc que tu utiliseras pas mieux

 
A partir de combien de couches d'abstraction entre la base de données et ton code tu te sens propre ?

 
j'ai encore en travers une migration Oracle sur sql server avec environ 400 proc stock utilisant du "MERGE INTO"

 
Faut au moins que le schéma puisse être transposé ainsi que les données migrées, après on voit

 
Ça reste complètement con comme approche, tu ne peux pas te limiter à l'ANSI SQL et utiliser 20% des capacités de ton produit sous prétexte qu'un jour, peut-être, tu migreras ta base vers une autre techno.

Et c'est Juste son prénom
J'ai relu la phrase 5 fois, j'ai aucune idée de comment brancher le merdier je crois qu'on verra un autre jour.

 
Et pourtant c'est devenu la tendance....
 
ici chez la banque à l’écureuil on n'a même plus le droit d'utiliser des proc stock (oui, vous avez bien lu... c'est prohibé !) dans cette optique... et ça rate pas un nouveau plan sur 2 ans prévoit de repasser sur oracle....
Idem, obligation de se cantonner au SQL ANSI...
 
Historiquement en 20 ans ils ont fait Sybase -> Oracle -> Sql server -> retour prochain sur Oracle...
 
Alors oui, ça peut paraître complètement con, mais économiquement c'est pas déconnant, tu transposes les schema, tu migres les données, et après tu adaptes ton fournisseur de données...
 
la première appli pilote a été migrée en 2 Jours grâce a ces conventions "à la con", le code a pu être réutilisé tel quel derrière, juste changer le DBProvider dans la config .NET de l'appli
 
je cautionne pas spécialement, mais c'est tout aussi efficace  
 

je sauve tout ça là
 

enfin tes contraintes sont quand même super spécifiques
 
Dans mon monde, le cadre ( legal, financier, humain, technologique) change complètement tous les 5 a 10 ans, rendant obsolète l'idée d'une migration. J'ai aussi l'obligation d'utiliser des index spécifique (notamment géographiques)
 
Quel est l'intérêt de choisir un fournisseur plutôt qu'un autre, si tu n'exploite pas les avantages d'une plateforme ? Pour le coup, la migration devient triviale, mais qu'est ce qu'elle apporte ?
 

 
Le soucis d'uniformisation du SI... en ce moment ça bouge beaucoup ici (intégration du crédit foncier, absorption totale de Natixis et Banque pop sous une seule et même enseigne BPCE IT), chacun avec ses spécificité et ses applis dans plein de techno différente. Et c'est oracle qui a payé le meilleur resto  
 
et ça c'est la première passe... dans un second temps on va devoir migrer toutes nos appli .NET vers du java/html5... (je serais barré de là depuis longtemps quand ça arrivera )
 
 

 
Merci pour le lien. J'ai trouvé Sinopia pour npm https://github.com/rlidwka/sinopia

 
Je me demande toujours comment ces théories complotistes apparaissent. On dirait presque une portion d'un background de jeu de rôle papier.  

J'ai jamais utilisé les vues. Je vais mater ça. Y'a une mécanique que j'ai mis dans les nice to have c'est l'envoi mails ou d'alertes quelques jours avant le changement de tarifs, je pourrais foutre ça dans la même tache cron.
 

SELECT 
    product.product_id, 
    price_ref.price 
FROM price_ref  
INNER JOIN product 
   ON  product.product_id= price_ref.product_id /*FK :, donc quasi gratuit */
         AND product.date BETWEEN price_ref.start AND price_ref.end /* pas FK , donc cout léger*/

Yes, c'est à quoi j'avais pensé.
 

Quelle idée de livrer un Vendredi aussi.
 

?
 

 
 
Nexus gère NPM depuis quelques version, utile si comme chez nous vous l'utilisez déjà pour d'autres types de dépendances.
Intéressés par vos retours sur un proxy Bower. private-bower merdais chez nous quand j'ai testé la semaine dernière, mais entre temps j'ai identifié un défaut sur notre proxy (HTTP).

Très intéressant.

Sinon chez nous, on a développé un système de download/update pour notre dernière version de XO, qui récupère des packages Npm stockés sur notre plate-forme de vente (donc faut se register dans l'appliance). Ya un "register" et un "updater" (qui gère l'update de lui-même, gestion de rollbacks et des scripts de migration si on change de BDD ou de schéma).

D'ailleurs ça ressemble à ça, pour les curieux : https://xen-orchestra.com/blog/xen- [...] xoaupdater

Et sinon +1 pour GitLab.
 
Tant que ta pas besoin de « social coding » (projet non Open Source ou petits), c'est vraiment excellent. L'affichage des branches et >>> à GitHub.