[AC] Gezamelijke voorraad tussen CO'ers

zou het nog een optie zijn om invulvelden uit te schakelen als je selecteerd wat voor onderdeel het is?

dus als je aangeeft dat het een transistor is, dat meteen de capaciteit ( in F ) en de samplerate uitgaan

zo hou je vanzelf minder vakjes over om in te vullen

nog een idee: voor bij voorbeeld de spanning, dat je het getal opgeeft dat op het onderdeel staat, en dan aanvinken of het mV, V of KV is ... en bij condensatoren pf,nf uf of F, en dat de waardes dan meteen omgerekend worden naar de standaard eenheid. zo hoeft het programma niet meer uit te gaan zoeken welke eenheid er nou bedoelt wordt, en zal het zoeken ook makkelijker gaan

Select boxes voor f, p, n, u, m, -, k, M, G, T, P zijn eventueel wel een optie, maar dit bevindt zich alweer op implementatieniveau.

Volgens jou (en daar kan ik me in vinden) moet een categorie ook nog de volgende informatie bevatten:

  • van toepassing zijnde attributen

Idee is heel goed, ik wilde het ook al eens aankaarten.

Maar om een app te bouwen speciaal hiervoor gaat te ver. Ondanks alle goede bedoelingen ben ik bang dat het snel uit de hand loopt. Dat blijkt wel uit de discussies.

Zoals BertM al zegt is gewoon een plain wiki server denk ik de meest snelle en pragmatische optie. Fatsoenlijke search engine erop en klaar.
Wel iets maken dat je de pagina's alleen zelf kunt editen. Hoe dat bij verschillende wiki's gaat is effe vers twee.

Als elke CO-er nu een pagina maakt die de naam van zijn nickname heeft ben je al helemaal klaar. De mijne zou dus worden:
http://dev.urandom.nl/wiki/index.php/Henri62

En daar een tabel in zetten met je onderdelen (volgens een template) in die template een link naar het CO-profiel zetten.

Sterk punt henri62, daar zie ik ook meer heil in. Zo'n persoonlijke wiki is btw ook goed te gebruiken als uitgebreid profiel/showcase. In het CO-profiel is een verwijzing naar de persoonlijke wiki goed te doen.

De andere opties tot zo ver gaan erg diep in op een grote database, maar op deze schaal heb je dan te maken met een database op bedrijfsnivo. En dat is geen kattepis, en niet iets om even te implementeren.

Zo'n wiki-pagina is inderdaad verrweg de eenvoudigste oplossing, met maximale flexibiliteit ;)

Op 3 juli 2011 19:51:12 schreef Henry S.:
De andere opties tot zo ver gaan erg diep in op een grote database, maar op deze schaal heb je dan te maken met een database op bedrijfsnivo. En dat is geen kattepis, en niet iets om even te implementeren.

Ik ruik een uitdaging!

Wat betreft de Wiki: ga gerust je gang ;)

Leuk probleem om jezelf in te verdiepen, maar ik zou eerst kijken naar de search-engines van de 'grote jongens', zoals farnell, rs en digikey... en ze werken geen van allen echt fijn.

(en het is maar zijdelings gerelateerd aan electronica..)

[Bericht gewijzigd door alex278 op (14%)]

hmm zoals BertM aangeeft: hoe link je dan je producten die je aanbied aan de gebruiker? daar zie ik nu niets ven terug.

ik denk echt gewoon 1 groot veld en idd aan of uitzetten wat niet nodig is..

Hmmja, mijn tabellenvoorstel is natuurlijk nog niet compleet. Er moet tenminste nog een extra tabel bij met user_id -> product_id. Ik zal het even aanpassen.

Hé, da's niet waar. In de producttabel staat al een user_id, laatste kolom.

[Bericht gewijzigd door Bert M op (22%)]

Een wiki heeft het voordeel dat je vrijwel niks hoeft te programmeren alleen wat configuratie werk.

Als het blijkt dat het goed werkt kun je alsnog de optie nemen om een fancy database + website te maken. Maar vergis je hier niet in!!!
Een goede website die niet om zeep geholpen kan worden (hacks/sql injection noem maar op) kost veel tijd om het goed te doen.

En maar niet te spreken als iemand die het gemaakt heeft het niet verder ondersteunen (wil/kan), dan moet iemand de code overnemen en helaas is in 95% van de gevallen de code niet of slecht gedocumenteerd zodat uiteindelijk het hele project verloederd.
Heel veel open source projecten sneuvelen hier op: Heel enthousiast aan het begin en binnen een paar jaar volledig dood gebloed. Helaas maar ik constateer dat nogal eens.

@ bert M je tabel met attributes is ellenlang en onlogisch van opbouw, immers range 1 tot 8 hoort bij entry 1 in de pordcut database, das niet handig

Ipv te programmeren waarom niet een standaard CMS (Joomla oid) met een webshop module ?

Groeten, Bram

Ook nog teveel werk, veel meer als een wiki.

Verder heb ik mijn eerste opmerking aan de wiki toegevoegd voor de parsing van getallen. Zo zie je maar dat de meest simpele dingen al mis kunnen gaan.

[Bericht gewijzigd door henri62 op (64%)]

ga in een wiki maar eens zoeken..
is een complete ramp.

Zo te zien is het nog een aardige klus om uit te vinden hoe je gemakkelijk data uit een database haalt. Mijn optiek: implementeer nu iets simpels, als een (optionele) omschrijving. Later kan kan andere gegevens om een component eruit te vissen worden toegevoegd. Een gezamelijke voorraad database was in de eerste instantie om te kijken of iemand nog zo'n 741'tje of net die ene weerstandswaarde heeft liggen. Later kunnen we dan ook zoeken of iemand een ADC met een samplingrate van meer dan 250kHz en een resolutie van 14 bits heeft. Het is niet in de eerste instantie om een component op eigenschappen te zoeken, maar meer een bepaald component op te zoeken (wat voor een condensatoren van 100nF hebben we zo liggen?)

Uit voorbeelden als Conrad, Farnell etc kunnen we opmaken dat het geen gemakkelijke klus is om een component te zoeken op parameters - en die lui verdienen er geld aan om jou dat te laten doen. Ik neem aan dat ze daar er ook eens goed over hebben nagedacht, met een baggersysteem als resultaat.

[Bericht gewijzigd door Dweil op (17%)]

Is er al iemand die dit gaat realiseren, ik ben webdeveloper en kan wel een dergelijk systeem maken.

Als dit dan een mapje op dit domein wordt kunnen de cookies gewoon worden overgedragen van het forum om de gebruikers te identificeren.

Op 3 juli 2011 21:28:55 schreef High met Henk:
ga in een wiki maar eens zoeken..
is een complete ramp.

Klopt. Maar dat is nog wel gedeeltelijk op te vangen met juiste keywords etc.

Ik zou het eerst eens CO-onafhankelijk maken, en dan later de koppeling met CO toevoegen. Om privacy en veiligheidsredenen, onder andere.

Met mijn voorgestelde databaseindeling is relatief eenvoudig een variabel aantal velden op te vragen, te begrenzen en te limiteren. Om bijvoorbeeld de weerstand, tolerantie en vermogen (en productnaam, id) van alle componenten met een weerstand tussen 100 en 200 Ohm op te vragen, volstaat de volgende query:


SELECT * 
FROM (
	SELECT
		prods.id AS ProductID,
		prodnaam AS Productnaam,
		SUM( CASE attnaam WHEN 'Weerstand' THEN attwaarde ELSE NULL END ) AS Weerstand,
		SUM( CASE attnaam WHEN 'Vermogen' THEN attwaarde ELSE NULL END ) AS Vermogen,
		SUM( CASE attnaam WHEN 'Tolerantie' THEN attwaarde ELSE NULL END ) AS Tolerantie
	FROM (
		SELECT
			producten.id,
			producten.naam AS prodnaam,
			attributen.naam AS attnaam,
			eigenschappen.waarde AS attwaarde
		FROM producten
		LEFT JOIN eigenschappen ON producten.id = eigenschappen.product
		LEFT JOIN attributen ON eigenschappen.attribuut = attributen.id
	) AS prods
	GROUP BY prods.id
) AS result
WHERE Weerstand >= 100 AND Weerstand <= 200
ORDER BY Weerstand DESC;

Op 3 juli 2011 21:54:06 schreef Stijntjhe:
Is er al iemand die dit gaat realiseren, ik ben webdeveloper en kan wel een dergelijk systeem maken.

Zogauw ik vrije tijd heb (lees: over een week) wil ik er wel wat aan gaan prutsen. Ik denk dat dat veel een aantal van ons geldt: iedereen wil er wel wat aan bijdragen. Ik weet niet of er onder ons iemand is die zoiets heeft van "dat maak ik wel even in m'n uppie", ik wil zelf bijvoorbeeld wel een poging wagen maar ik garandeer natuurlijk niets.

Samenwerking op de een of andere manier lijkt me zeer nuttig, mits we de taken goed kunnen verdelen. Maar als je denk zelfstandig zoiets in elkaar te kunnen zetten met goed resultaat, voel je dan niet geremd wat mij betreft.

Ik ben nu met name even wat aan het spelen met databasestructuren en queries om daar de gewenste data uit te trekken.

[Bericht gewijzigd door Bert M op (28%)]

Het is wel makkelijker om het gelijk te koppelen met CO, anders moet je later ineens alle gebruikers gaan matchen en je weet niet welke gebruiker in de applicatie bij welke op CO hoort.

Niet iedereen is zo eerlijk om z'n eigen gebruikersnaam in te vullen.

[Bericht gewijzigd door Stijntjhe op (16%)]

Op 3 juli 2011 22:33:57 schreef Stijntjhe:
Het is wel makkelijker om het gelijk te koppelen met CO, anders moet je later ineens alle gebruikers gaan matchen en je weet niet welke gebruiker in de applicatie bij welke op CO hoort.

Dan kan alleen Jeroen er mee bezig, en die heeft het al druk zat.

Op 3 juli 2011 22:33:57 schreef Stijntjhe:
Niet iedereen is zo eerlijk om z'n eigen gebruikersnaam in te vullen.

Tsja, dat is dan jammer. Maakt ook niet zoveel uit: een later koppeling vereist alleen een lege uitrol van het systeem en een methode om je gegevens over te zetten.

Het is maar een kwestie van de sessie id op te halen uit de cookies, en dan aan de hand daarvan de gebruikersnaam en gebruikers ID uit de tabel met gebruikers van CO te halen.

Het enige wat nodig is om het systeem te kunnen maken is een dump van de gebruikerstabel. Hieraan worden dan een aantal velden toegevoegd zoals "Woonplaats" etc.

Later kan het systeem dan op CO worden gezet en na het toevoegen van de velden in de database van CO werkt het systeem vanzelf.

[Bericht gewijzigd door Stijntjhe op (16%)]

Als we effe praktisch blijven en http://dev.urandom.nl/wiki/index.php gebruiken en iedereen daar zijn zooi op zet kun je vandaag nog aan de slag!

Wel de pagina exact zo noemen als je nickname.

P.S. De table extension aan de wiki toevoegen is ook wel zo handig.
Ik zal dat eens uitzoeken hoe dat moet deze week.

[Bericht gewijzigd door henri62 op (24%)]

Valt niet op te zoeken...? Hoe ga je daarin per component zoeken?

Dat is de meest simpele: Gewoon letterlijk op het type.
Dat is denk ik het meest gebruikte soort zoekopdracht

Ranges zijn veel beroerder.

[Bericht gewijzigd door henri62 op (24%)]