Dit aantal van 260 tekens is over het algemeen meer dan voldoende voor de classificatie van documenten, vooral als we bedenken dat EPDM in de eerste plaats een databank is die het gemakkelijk maakt om alle documenten die daar zijn opgeslagen te vinden, op voorwaarde dat de variabelen die als zoekcriteria worden gebruikt, oordeelkundig worden gedefinieerd. In het voorbeeld dat voor de mapnaam wordt gegeven, zou ik de neiging hebben om vloeren te verwijderen en woordenboeken, vooraf gedefinieerd en alleen bewerkbaar door een beheerder, in gegevenstoewijzingen te plaatsen, zoals:
dico 2 : Glijlagers / Lagers / ... => dit woordenboek is een subwoordenboek van Rotatiebegeleiding
DiCo 3 : Cilindrisch / geflensd / ... => dit woordenboek is een subwoordenboek van glijlagers
plus 1 vrij invoerveld: Ø28xØ22x16
De volledige aanduiding kan in een veld staan dat wordt berekend op basis van bepaalde niveaus van de woordenboeken, hier: Glijlagers met flenzen Ø28xØ22x16, een waarde die in de nomenclaturen kan worden weergegeven.
EPDM hebben om projectbestanden te beheren is één ding.
Het is erg belangrijk om een 3D-bibliotheek te hebben die gebruikers "matcht".
(klassieke mappenbibliotheekmethode: Brand-Maker, of generieke elementen in mappen met een overeenkomstige naam)
Het hebben van een gedwongen ontwerpbureau vanwege EPDM om voortdurend onderzoek te moeten doen voor een bibliotheek is een "FOUT" en vooral een kolossale tijdverspilling voor het jaar, niet te verwaarlozen, het is onaanvaardbaar voor een ontwerpbureau...
Een computersysteem of software mag gebruikers niet opleggen "een handeling die niet overeenkomt met hun behoeften" (in dit geval de CAD-bibliotheek).
Dus om vooropgezette ideeën te stoppen:
het hebben van een EPDM mag gebruikers niet dwingen om met de CAD-bibliotheek te werken door voortdurend te zoeken...
Het tijdverlies dat dit het hele jaar door betekent, is kolossaal...
En ter herinnering, de Solidworks-filosofie van een bibliotheek wordt gebruikt met het rechterpaneel "Design Library"
Het antwoord op de vraag is dus: ja, EPDM kan 151 tekens aan.
Zoals ik het begrijp, is de rest gewoon een verschil van mening tussen degenen die de voorkeur geven aan EPDM als database en degenen die de voorkeur geven aan EPDM als Windows Verkenner.
Wat betreft de opmerking " Het hebben van een gedwongen ontwerpbureau vanwege EPDM om voortdurend onderzoek te moeten doen voor de bibliotheek is een "FOUT" en vooral een kolossale verspilling van tijd per jaar, niet te verwaarlozen, het is onaanvaardbaar voor een ontwerpbureau... ", dit kan worden besproken, zonder boos te worden, en wat voor de ene BE onaanvaardbaar is, kan voor de andere onaanvaardbaar zijn, afhankelijk van het aantal te beheren dossiers en de interne organisatie van elk bedrijf...
@ olivier42, als je schrijft " We zijn niet verplicht om voor beide dezelfde methode te gebruiken, integendeel ", ben ik het volledig met je eens en ik heb niet geschreven dat we verplicht zijn om een bibliotheek te hebben die alleen werkt door onderzoek, Het hangt er ook vanaf wat je achter de woordenbibliotheek zet. En ja, het doorlopen van onderzoek kan wat langer duren voor het ontwerpbureau, maar afhankelijk van de algehele werking van het bedrijf, is het echt tijdverspilling voor, want na het ontwerpbureau komt het Methodenbureau, de Inkoopafdeling, Productie, enz... en dan communiceert EPDM van tijd tot tijd met een ERP... Voor mij moet dit een globale reflectie inhouden en niet alleen het BE-gebruikersaspect.
Ik heb ook beide methoden gezien en geoefend, en omdat ik duizenden bestanden heb moeten ontdubbelen en opschonen die zijn opgeslagen in de typeclassificatie van Windows Verkenner, geef ik er de voorkeur aan om een database te gebruiken, zelfs met de weinige beperkingen die dit met zich meebrengt...
Precies, na beide methoden te hebben geoefend, geef ik de voorkeur aan degene die compatibel is met het solidworks-paneel.
Dit stoort de andere diensten op geen enkele manier, hun onderzoek/werk blijft volledig compatibel.
Aan de andere kant heeft de onderzoekstijd het hele jaar door voor een ontwerpbureau een monumentale prijs!
de "klassieke SW"-methode stelt u in staat om onmiddellijk te werken (compatibel met configuratiebibliotheken!!)
De "zoek"-methode verspilt enkele minuten per dag, uur per week, enz... (want daarnaast moet je soms zoeken met verschillende trefwoorden, spatie, komma, punt, etc...) Want ja, zelfs de "onderzoeks"-methode kan volledig vervuild zijn.
Na een schone bibliotheek kan het worden beheerd, en degenen die het "oppoetsen" hebben er geen toegang toe, of met externe validatie.
Een schone "klassieke SW"-bibliotheek kan dus zonder enig probleem zo blijven.
Ik werk al jaren op deze manier, de winst is fantastisch (beperkingen auto's en bedrijven...)
Ik ging terug naar een ontwerpbureau met de "onderzoeks" -methode, ik zag meteen de traagheid toevoegen aan mijn projecten. Ik heb echt het gevoel dat ik werk met een archaïsche methode uit het stenen tijdperk, die 15/20 jaar oud is...
Om nog maar te zwijgen van het feit dat de "zoek"-methode repetitieve taken omvat die in 3D kunnen worden gebruikt. Terwijl ze bij de "klassieke SW"-methode verdwijnen.
Ja, dus we zijn natuurlijk geen verschil van standpunt tussen een databasetypeclassificatie en een Windows verkenner-typeclassificatie, beide oplossingen hebben hun voor- en nadelen, deze zijn zeker sterk afhankelijk van de werking en interne procedures van elk bedrijf.
Wat zeker is, is dat het vanaf het begin goed doordacht moet zijn om een optimale werking te garanderen en het risico op fouten te minimaliseren, zoals:
- Definieer voor de typezoekmethode duidelijk de woordenboeken (trefwoorden) die het mogelijk maken om de volledige naam van het bestand in te vullen (geen risico op spelfouten of tekens zoals spaties of komma's, aangezien het woordenboeken zijn).
- Voor de methode van het type Verkenner, zorg ervoor dat elke persoon die een item in de bibliotheek maakt, de gewoonte van het benoemen van het nieuwe bestand respecteert en het vooral opslaat in de map waarin het anders zou moeten staan!!!!!
- Definieer in beide gevallen duidelijk wat een bibliotheekelement is en wat niet.
In het gegeven voorbeeld (kraag glijlager Ø28xØ22x16) en in het bedrijf waar ik werk, is het geen bibliotheekelement omdat het een commercieel element is met een interne code die verband houdt met een artikel in ons ERP en verloren is gegaan in het midden van ongeveer 5 tot 6000 elementen, dus bestanden, van hetzelfde type. Ik kan me niet eens voorstellen hoeveel bestanden er nodig zouden zijn om ze allemaal in te dienen. Het zoeken van het type verkenner zou veel tijd in beslag nemen en zou onverbiddelijk leiden tot het aanmaken van een duplicaat en dus tot een aanzienlijk tijdverlies voor andere afdelingen (methoden, aankopen, winkels, enz.), om nog maar te zwijgen van het financiële verlies voor het bedrijf dat een duplicaat artikel kan vertegenwoordigen (voorraadbeheer, enz.).
De enige goede methode is degene die het beste past in de algehele werking van het bedrijf, of deze operatie nu archaïsch is of niet.
Juist de "Classic SW (map)"-methode maakt het mogelijk om:
Hiermee kunnen gebruikers direct werken tijdens het ontwerpen.
Om het juiste paneel te gebruiken.
Om onderdelen in configuratie te gebruiken (of niet) (terwijl u een systeem onder EPDM heeft)!!
En om altijd "Zoekopdrachten" te kunnen doen als dat nodig is (als je in de "Zoek"-modus wilt werken)
(Maar goed, het is beter om deze discussie niet voort te zetten, die verre van het onderwerp is, we hebben misschien de gelegenheid om erover te debatteren over onderwerpen die hieraan zijn gewijd)
Blij dat ik je heb kunnen helpen, aan de andere kant zie ik het antwoord op je vraag niet in het beste gekozen antwoord, wat het zoeken niet gemakkelijker maakt voor degenen die dezelfde vraag zouden kunnen stellen.