Gamesbond
Enige overeenkomst tussen wat hierboven staat en de werkelijkheid berust op puur toeval
@allround:
excel is een mogelijlijkheid, al lijkt deze me minder geschikt :
iedereen moet zijn info op dezelfde manier opslaan, er kunnen problemen zijn door verschillende excel versies, heeft iedereen excel?, en aan de serverkant moet er nog een omvorming gebeuren excel<->database.
een deel hiervan kan vermoedelijk opgelost worden met VBA, maar dan denk ik dat het simpelder is om te werken met een applicatie, die rechtstreeks contact heeft met de database, eventueel met de mogelijkheid om excel te importeren
Dweil
1 electron per seconde = 16 atto ampere!
Voor zoekfuncties: Te denken valt aan een parser, die voor de spanning een bepaalde basiseenheid berekend. Voor diegene die dus net voor hun hoogspanningscondensator 3000000000000nV heeft ingevuld, wordt dat opgeslagen als 3000V. Als dan later iemand die condensator nodig blijkt te hebben en 3 KV invult (met een spatie dus) word dat omgerekend naar 3000V en komt die bewuste condensator er dus uit.
ik zal wel kijken of ik vandaag ff iets kan freubelen in PHP en mysql, want ik huiver beetje van excel en lokale applicaties...
hoe moeilijk kan het zijn om ff snel iets in te voeren? zoveelw erk is het niet om iets dedicated te schrijven..
ik zal wel ff kijken of ik paar uurtjes overheb...
[Bericht gewijzigd door High met Henk op (24%)]
Op 3 juli 2011 11:08:01 schreef Dweil:
Dat hele "Knopje hier, invulveldje daar" is voor mij net goed om er over blijven na te denken, en zo gaandeweg dingen te verbeteren. Ik ben zelf ook slecht in webdesign, maar gelukkig zijn er van die Online form creators.
Ik denk dat we ons hiermee te sterk zouden vastleggen in het aantal velden. Zo wil je van een kristal waarschijnlijk geen spanning opgeven, maar weer hele andere gegevens. Of van een ADC het aantal bits, samplefrequentie, etc.
Zo denk ik dat we naar een variabel aantal velden moeten, waarbij gebruikers eventueel zelf velden toe kunnen voegen. Een veld heeft dan mogelijk ook een gekoppelde eenheid (bijvoorbeeld Farad), waardoor alle gebruikers tenminste dezelfde eenheid aanhouden.
Ik zou ook absoluut gaan voor een online applicatie, eventueel aangevuld door een lokaal iets. Zo hou je ook Linux / Mac gebruikers tevreden.
kijk even op de onderdelen bestel site die ik ooit gemaakt heb (JAREN terug) voor mijn vader: http://www.ural.eu en dan onderdelen klikken.
ik heb het nooit afgemaakt, maar het werkt wel
een complete catalogus zit er niet aan want alles digitaliseren was onbegonnen werk.
maarem we kunnen er natuurlijk wel een database entry van maken ipv een e-mail.
Aantal velden zou ook horiznataal uitbreidbaar kunnen zijn, maar dat maakt het nagenoeg onmogelijk om zoiets in een database te doen, of je moet in de database alle denkbare velden al predefined hebben...
das nogal een klusje.
Dat lijkt zo, maar je hoeft niet alle velden predefined in tabellen te hebben. Je kan het ook anders aanpakken: maak een tabel met "vaste" data: componentid, gebruiker, datum, ...
Daarnaast maak je dan een tabel met componentid, attribuutnaam, attribuuteenheid, attribuutwaarde. Zo kan je dynamisch (getals)attributen toevoegen.
-- Edit: beter nog: je maakt daarnaast een tabel met attributen (attribuutid, naam, eenheid) en een tabel met componentattributen (componentid, attribuutid, waarde). Dat is generieker en beter te onderhouden.
Even bezig geweest met een kort stukje code dat de meestvoorkomende getallen + eenheden kan parsen:
<?php
function parseInvoer($invoer)
{
$eenheden = array("Hz", "s", "F", "H", "J", "C", "V", "A");
$ordes = array("f" => -15, "p" => -12, "n" => -9, "µ" => -6, "u" => -6, "m" => -3, "k" => 3/*, "K" => 3*/, "M" => 6, "G" => 9, "T" => 12, "P" => 15);
$invoer = trim($invoer);
// Vind de langste postfix eenheid
for ($i = 1; $i < strlen($invoer); $i++)
{
if (in_array(substr($invoer, $i), $eenheden))
{
$eenheid = substr($invoer, $i);
$invoer2 = trim(substr($invoer, 0, -strlen($eenheid)));
// Als de invoer al numeriek is, stond er geen orde vermeld
if (is_numeric($invoer2))
{
return array("eenheid" => $eenheid, "waarde" => $invoer2);
}
// Zoek en parse de orde
if (array_key_exists(substr($invoer2, -1), $ordes))
{
$waarde = pow(10, $ordes[substr($invoer2, -1)]) * $invoer2;
return array("eenheid" => $eenheid, "waarde" => $waarde);
}
}
}
return false;
}
print_r(parseInvoer("3.2 MHz"));
?>
Even iets tussendoor;
Vind het zelf ook een uitstekend idee!!
Er zij blijkbaar behoorlijk veel mensen die hier hun tijd en spullen in willen investeren.
Nu er nog niets echt vast staat is het mischien mogelijk om de mensen te belonen die er veel of het meeste werk in hebben gestoken, en niet te vergeten diegenen die het systeem onderhouden?
ALs er bijv. voor een onderdeel betaald wordt kan er dan niet bijv. 2 of 5 % van het bedrag naar de systeembeheerder/onderhoud gaan?
Dat geeft meteen een beetje garantie dat het soepel blijft lopen en het is eerlijk, toch?
mijn 2 cents
Op 3 juli 2011 12:07:00 schreef Bert M:
[...]
Ik zou ook absoluut gaan voor een online applicatie, eventueel aangevuld door een lokaal iets. Zo hou je ook Linux / Mac gebruikers tevreden.
Als je een Java applicatie maakt zijn Windows, Linux, Mac, en zelfs een paar mobiele gebruikers tevreden. Dit gewoon even om aan te geven dat er vaak alternatieven te vinden zijn.
Zo denk ik dat we naar een variabel aantal velden moeten, waarbij gebruikers eventueel zelf velden toe kunnen voegen. Een veld heeft dan mogelijk ook een gekoppelde eenheid (bijvoorbeeld Farad), waardoor alle gebruikers tenminste dezelfde eenheid aanhouden.
Vrije configurabele velden leiden vaak tot onnodig complexe applicaties. Voor je het weet maak je er een formulieren editor met scripting mogelijkheden bij. (En gaat het richting MS Access / Ms Excel qua functionaliteit) Het te flexibel maken van een applicatie is een valkuil, deze wordt veroorzaakt door het gebrek aan een ontwerp / analyse. Een gedegen ontwerp voorkomt de noodzaak voor dat soort dingen. Tenzij het je doel is om een applicatie te maken die in veel verschillende situaties ingezet kan worden. Maar dat is hier niet aan de orde.
Wat betreft het parsen van invoer, regular expressions zijn daarvoor vele malen geschikter. (sterker nog, ze zijn er voor gemaakt). Ze voorkomen grote lappen code om een eenvoudige invoer te kunnen ontleden.
Het is niet mijn doel het project / iemand / de groep / etc. af te branden. Ik vind het een prachtig initiatief. Daarom wil ik proberen duidelijk te maken welke standaard fouten vaak optreden bij dit soort projecten.
Inventariseer eerst maar eens wat er gemaakt moet worden, en wat er vastgelegd moet worden. Daara komt het hoe wel.
[Bericht gewijzigd door mbbneon op (11%)]
maar dan zit je nog met een aantal attributen dat je kwijt kan.
bijv. een simple mosfet:
Vgs, Vd-s, RDS-on max power, G capaciteit, turn on delay enz. enz.
Je zit zomaar soms op 8 attributen, die moet je dan naar je andere tabel laten wijzen met je waarden die je in kunt stellen. Dus ipv 1 kolom met het attribuut in de kolom en zijn waarde in de tabel, moet je nu ineens per attribuut opgeven welk attribuut het is en welek waarde hij heeft, dus ipv 8 predefined kolommen zit je nu ineens in 16 variabele kolommen...
denk niet dat dit handig is...
De onhandigheid daarvan valt best wel mee, er zijn allerlei SQL statements die het mogelijk maken met dat soort gescheiden informatie om te gaan.
Hoe dan ook, ik denk dat mbbneon wel een punt heeft dat we ons eerst moeten focussen op het wat, en daarna pas op het hoe.
Op 3 juli 2011 13:23:18 schreef mbbneon:
Wat betreft het parsen van invoer, regular expressions zijn daarvoor vele malen geschikter. (sterker nog, ze zijn er voor gemaakt). Ze voorkomen grote lappen code om een eenvoudige invoer te kunnen ontleden.
Ik heb daarover nagedacht, maar ik kon zo gauw geen manier vinden om iets vergelijkbaars te doen met regular expressions. Als je een betere oplossing hebt, dan zie ik die natuurlijk graag 
Op 3 juli 2011 13:23:08 schreef bitbanger:
Nu er nog niets echt vast staat is het mischien mogelijk om de mensen te belonen die er veel of het meeste werk in hebben gestoken, en niet te vergeten diegenen die het systeem onderhouden?
ALs er bijv. voor een onderdeel betaald wordt kan er dan niet bijv. 2 of 5 % van het bedrag naar de systeembeheerder/onderhoud gaan?
Dat geeft meteen een beetje garantie dat het soepel blijft lopen en het is eerlijk, toch?
Nee, dat is niet eerlijk. Ook al zou het niet gek zijn dat de beheerder(s) iets ontvangen voor hun diensten onkosten (om bijvoorbeeld de server draaiende te houden, programmeerwerk zie ik meer als vrijwilligerswerk in deze), een percentage van de verkoop levert altijd problemen op. Voor je het weet ben je een geheel betalingssysteem aan het inrichten en leg je allerlei eisen op aan de koper/verkoper waardoor het systeem net eBay wordt.
Ook ben je als je kosten rekent voor de transactie, ineens een partij in de koopovereenkomst. Dat is een bijzonder slecht idee. Beter verzorg je alleen het platform, en maak je een "tip jar" of gebruik je Google Adwords om aan je inkomsten te komen.
Lijkt me een zeer handig idee, zeker voor de obsolete zaken.
Een 2e invoerveld naast de avatar, waar een excel-sheet in gelinkt wordt, en een zoekfunctie om in die lijsten van co'ers te kunnen zoeken lijkt mij voldoende. Degene die een lijst hebben, kunnen deze bijwerken als nodig, en via de link is deze dan ook up to date.
<spam>
Bijvoorbeeld : http://www.richvermeer.nl/sellingstock.htm
</spam>
Hier heb ik de lijst wel als htm gesaved, zodat hij zo op de server kan, maar als xls is natuurlijk mogelijk.
De lijst is trouwens niet echt actueel...
Om het nou gelijk een onderdeel van de CO-site te maken lijkt me eerlijk gezegd een brug te ver.
Op 3 juli 2011 13:23:57 schreef High met Henk:
dus ipv 8 predefined kolommen zit je nu ineens in 16 variabele kolommen...
Ah, you're gonna love this.
Denk niet in tabellen. Je hebt een tabel met daarin een artikelnummer voor een onderdeel, een beschrijving (tekst), en een tekstveld waarin je alle parameters opslaat, als een JSON-string. Dus iets als {Rds:1, Vmax:800, Cds:0.0001, datasheet:"http:/blah"}, etc.
Die JSON-string kun je ophalen, naar je webpagina sturen met wat ajax of inline templaten, en de javascript die achter je webpagina zit kan dan die JSON-string omvormen tot een javascript-object en daar van alles mee doen. De lol hiervan is dat je flexibel blijft (je kunt alles in zo'n json-object duwen, ook andere json-objecten, dus {{pootje1: Vcc, pootje2:Vdd}, Vmax:5} en dat je alle info in *een* databasetransactie kunt oplepelen.
(het alternatief is een tabel 'parameters' met een 3tal-velden: id, parameternaam en inhoud-veld. Voor standaardlookups gaat dat beroerd performen, omdat je voor alles op die parametertabel moet querien. Alleen als je gaat zoeken op parameters heeft het een voordeel om al die parameters los op te slaan in een aparte tabel.)
Je kunt dit principe ook verder doorvoeren; je kunt ook dingen doen als 'kwak iedereen die objectnr 23874 heeft in een apart veld, met daarin een stukje JSON waarin je de bezitters aangeeft'. Effectief zet je dan een tabel in een andere tabel.
Databasefanaten gaan nu ongetwijfeld 'heiligschennis' roepen, maar ach, de ideale database van een databasefanaat is er een die in beton gegoten is en die geen gebruikers heeft.
Hoe wou je dat precies gaan opslaan? Naar mijn weten is JSON slechts een uitwisselingstaal, net als XML. Beiden zijn niet erg effectief te doorzoeken op parameters.
Gewoon, opslaan als tekst, en die tekst opslaan in een varchar(zoveel) of text-veld van je databasetabel.
Werkt prima als je data alleen wil bekijken. Doorzoeken is minder fijn, omdat je het parameterveld van ieder record moet terugvertalen naar een object voor je het kunt doorzoeken.
In een fatsoenlijke programmeertaal als python kun je zo'n object ook aan de server-kant bekijken, met cjson.decode(). Zoiets zal ongetwijfeld ook wel in php kunnen.
Databases als mongodb hebben 'ingebakken' JSON-support. Hoef je zelf die encodeer/decodeer slag niet meer te maken. Geen idee of je ook kan queryen op die JSON-velden (en wat de performance daar van is). Je gaat dan wel een aardig eindje riching het 'nosql'-kamp.
Even zeer kleine opzet tot een benadering van een geheel andere kant: een gebruikersgericht model. Even geen user interfaces, databasetrolls en scriptingtaalbashing, maar back to the basics.
Aanvullen en wijzigen wordt gewaardeerd (bijvoorbeeld op deze wikipagina).
Actoren:
- koper
- verkoper
- beheerder
Use cases:
- koper
- product zoeken
- vraag plaatsen
- contactgegevens opvragen
- verkoper
- product plaatsen
- product verwijderen
- product bijwerken
- vragen inzien
- beheerder
- categorieen beheren
Objecten:
- product
- naam
- eigenschappen
- beschrijving
- prijs
- verkoper
- vraag
- naam
- eigenschappen
- beschrijving
- prijs?
- categorie
- naam
- beschrijving
- producten
- vragen
en daar dan een index op, nee geweldige optie....
lijkt mij binnen no time een rete zware applicatie. Maar ik doneer wel een raid server
Ik zou eigenlijk zo ver willen gaan de product eigenschappen te schrappen. Daarvoor kun je link naar een datasheet gebruiken (indien gewenst).
Parametrisch zoeken is mijns inziens ook niet echt nodig.
Verder is het natuurlijk de vraag of je wilt dat mensen actief producten gaan aanbieden. (commercieel). Het is dan beter om van een vraag uit te gaan. "Ik zoek een ....." en geen aanbod te tonen.
Als vrager en aanbieder uiteindelijk met elkaar in contact komen is dat voldoende.
Anders ben je niets anders aan het maken dan een webshop waarbij de locatie van items ook buiten het magazijn kan zijn.
Aanbieden betekent hier in mijn interpretatie: "ik heb dit component eventueel beschikbaar". Dat was volgens mij ook het idee van dit systeem: een gezamelijke database van beschikbare onderdelen, waar je in kunt zoeken als je zelf een onderdeel mist.
Parametrisch zoeken lijkt me in die zin juist weer heel nuttig, om het overzichtelijk te houden. Zo ben je bijvoorbeeld niet op zoek naar een weerstand (dan pak je wel een ijzerdraadje), maar specifiek naar een weerstand van 130 Ohm.
Maar inderdaad, commercieel aanbieden van producten lijkt me ongewenst. Het moet m.i. echt een "ik heb dit liggen, ik gebruik het niet en als je het toevallig nodig hebt kan ik het wel in een envelop stoppen"-systeem worden.
Wat betreft je idee om eigenschappen te schrappen: lijkt me niet heel handig, van sommige onderdelen weet ik wel eigenschappen maar heb ik geen datasheet (weerstanden bijvoorbeeld). Maar het toevoegen van een link naar een datasheet is natuurlijk altijd handig.
[Bericht gewijzigd door Bert M op (16%)]
tja, ik denk gewoon idd aan een tabel met heleboel kolommen, waarvan je invult wat relevent is als attribuut idd.
makkelijk zoeken.
Het is alleen even zaak om die attributen aan te maken.
dat lijkt mij de beste optie en het eenvoudigst te implementeren.
Is er ondertussen al meer duidelijkheid over hoe al de info wat er gaat worden weergegeven?
En gaat dit ook in categorieën onderverdeelt worden zoals V&A op CO (evt meerdere opties mogelijk)
Mijn idee over hoe je info van een componentje kan weergeven:
cat: componenten
subcat: weerstanden
waarde: x Ohm
tolerantie: x%
aangeboden door:
Watchout3:
prijs: Ruilen/PNOTK
woonplaats: Rillaar
extra:
aantal beschikbaar: 50
soort: metaalfilm
fabrikant: Vishay
behuizing: TH
vermogen: 1/4W
toestand: NOS
XXX:
prijs: €0.02
woonplaats: mijndorp
extra:
aantal beschikbaar: mail voor quota
soort: kool
fabrikant: onbekend
behuizing: SMD
vermogen: 1W
toestand: nieuw
YYY:
prijs: ruilen
woonplaats: mijndorp
extra: [geen verdere info opgegeven]
cat: componenten
subcat: OpAmp
type: 741
voeding: Single supply (5-15V) /Rail to Rail (5-12V)
toepassing/eigenschappen: general/HF/lownoise
snelheid: xxx
aangeboden door:
Watchout3: Ruilen/PNOTK
woonplaats: Rillaar
extra:
aantal beschikbaar: 10
fabrikant: ST
behuizing: DIP8
toestand: nieuw
XXX: €0.10
woonplaats: mijndorp
extra:
aantal beschikbaar: 4
fabrikant: OnSemi
behuizing: SOIC8
toestand: nieuw
YYY: ruilen
woonplaats: mijndorp
extra: [geen verdere info opgegeven]Ik vermoed dat de meesten die een voorraadje weerstanden aanleggen bij eenzelfde 'familie' blijven (bvb: metaalfilm/ 1%/ vishay), dus het zou handig zijn om een 'voeg waarde toe' knopje te hebben
Ik heb misschien nogal vrij veel informatie gekozen, maar ik denk toch dat ik niet al te hard overdreven heb 
Ook moeten niet alle velden verplicht worden vind ik.
Vage situaties zoals aanbieder YYY, kunnen misschien best vermeden worden.
Bij de zoek functie zou het ook leuk zijn als je kon zoeken op locatie, zodat je evt zelf kan langsrijden, en dus verzendkosten besparen. (evt in het begin enkel sorteren op provincie en geleidelijk aan dit uitbouwen)
Ik probeer even je "hoe"-argumenten te omzeilen en je "wat"-argumenten samen te vatten.
Nogmaals, "hoe" het weergegeven wordt is het laatste probleem. Eerst maar eens de data overzichtelijk zien op te slaan en doorzoeken, als we uberhaupt vast hebben gesteld welke data er opgeslagen moet worden.
- onderverdelen in categorieen
- extra use case voor verkoper: een product klonen en aanpassen
- mogelijkheid tot zoekresultaten sorteren op locatie
Overigens zie ik ergens in het midden een "mail voor quota" staan: dat lijkt me in alle gevallen van toepassing. Het is geen webshop, dus is er geen sprake van een aanbod noch leveringsverplichting. Het is slechts een (hopelijk redelijk up-to-date) overzicht van iemands inventaris, waar je met een beetje geluk uit kunt vissen.
Ik heb me inderdaad verkeerd uitgedrukt. Hetgeen de ontwikkelaars nu moeten weten is 'wat' er in de database moet
'hoe' ze dit moeten doen is hun probleem
Mail voor quota is ook nogal ongelukkig gekozen vrees ik, maar ik vind toch dat je een minimum aantal moet plaatsen dat je ter beschikking kan stellen. (en dat de 'mail voor quota' meer doelt op; 'ik kan nog wel wat van mijn persoonlijke stock missen, maar mail voor verdere info/aantallen')
Totale beginner
LTE-M/NB-IoT/WiFi/BLE/GNSS - https://www.quickspot.io
Dit vind ik een fantastisch idee, ik kan zelf heel goed overweg met php, MySQL, HTML, CSS maar ook Java en in mindere mate .NET
Ik zou inderdaad werken met een relationele database met daarin de gebruikers&info en componenten&info. De gebruikers kunnen extra info over het component toevoegen zonder dat er extra kolommen in de database voorzien moeten worden.
Ik bedoel dus het volgende. Een tabel componenten ziet er als volgt uit
|id|typenr.|naam|waarde|extra|
------------------------------
|01|16F628A|----|------|pincount=18&Memory=3.5&...
In php moet dan enkel de parse_str functie aangeroepen worden op de waarde in de kolom extra en alles kan weergegeven worden.
Mvg,
TB
En dan wordt het ontzettend duur om een parametrische zoekfunctie toe te voegen.
Ik zou liever iets in deze sfeer zien:
tabel producten:
id | naam | beschrijving | verkoper
---|-------|--------------|---------
1 | NE555 | Timer IC | 1
tabel verkopers:
id | naam | woonplaats
---|--------|-----------
1 | Bert M | Houten
tabel attributen:
id | naam | eenheid
---|---------------|--------
1 | Max. spanning | V
2 | Max. freq | Hz
tabel eigenschappen:
prod_id | attribuut | waarde
--------|-----------|-------
1 | 1 | 5
1 | 2 | 100000
-- edit: klein foutje gefixt in de attributentabel