[TheSasquach]

What has become of the part numbers board idea? was hyped on that one. ......... just curious.

 

[Sam Simpson]

Thanks for reminding me. Anybody wanna help me code this out? It won't be too hard, we just need to figure out our approach first, the design is the hard part, coding is the easy part.

 

[TheSasquach]

Glad to be of service oon the reminder. ....... i can get most things done on a comp via operating windows. but other than that im no good with doing much else ........ if i can help in any way let me know. and im more than willing to help keep things organised on that board. espicaly in tye area of editing and checking numbers. David

 

[Sam Simpson]

We need to think of a good way of cataloging the info. I think our biggest concern before was the fact that parts fit multiple years.

 

[TheSasquach]

how about this. ..... we list and do a search by part then have the different applications with numbers listed under that. for example.


Water pump
72-74
318 340 360
Mopar # xxxxxx
napa #xxxxxx
ect ect

but basicly when you search for water pump you wil get all of them listed. and have to sourt tru all of them to find what you need. ........ i realy dont know what we can do as far as a search then a sub search with in that catagory. let me know and maby we can work from there. David

 

[Sam Simpson]

the hard part is the years.

If we listed it as 74-78, what if someone searched for water pump for a 77. It wouldn't turn up.

 

[TheSasquach]

well my thought was you dont use the year in the search. ........ so you look up water pump .... all the water pumps come up and you have to find your year range in there. David

 

[IntenseImages]

so waht you are saying sas, is that it would come up like this



Water pump water pump water pump
72-74 74-83 84-92
318 340 360 318 340 360 318 340 360
Mopar # xxxxxx mopar #xxxxxx Mopar # xxxxxx
napa #xxxxxx napa #xxxxx napa #xxxxxx
ect ect etc etc ect ect

if so then i like this idea.

the only question i would have, how are you going to solve it for different sized engines. for instance if you type in water pump, is it going to list all water pumps, both big and small block. or are you going to have to type in engine size/water pump?

just a thought

also sas, if you need any help, such as cross referencing numbers and such after we get it going, let me know. i wouldnt mind helping out.

eric

 

[Sam Simpson]

I think we need to fill out all the blanks, that way we can search by anything. I am going to think of a way to auto fill in all the years, so if 74-80 was selected, it would submit the part for every year.

I guess the same would have to be done with engine sizes too.

Anything else? We need to distinguish what part number it is, mopar, autozone, etc.

Actually, we will have fields for all the possible companies, that way when you search for water pump, it will show the year or years, engine sizes and each different part number.

 

[IntenseImages]

want to get started right now?

here is your first number sas

center ball package/front driveshaft 1987 ramcharger
dodge part number 4049697


just had the unfortunate experience of having to find this out. lol

eric

 

[santak]

uhm, just an idea with all this 73-80 and 82-85 thing...

if you select at the beginning the year, say 1987 and then want to look for a waterpump, that is in the DB as waterpump 84-89, there might be a chance of parsing out the 84 and 89, convert them to an integer, and make a simple comparison:

if (84 <= year <= 89) then
whatever

just a thought, the parsing shouldn't be too complex on a first thought...
of course we would need to keep the years in the same fashion in order to make it work, not mixing 2 and 4 digit years but pinpoint it down to one format.

 

[Sam Simpson]

I know what I can do, if the years are 84-89, I can write up a for loop that will take the variable = 84, loop it and add 1 to it, till it become 89. Then, under the years field, with it being a text field in the database, would be listeds as 84 85 86 87 88 89 and if we did querry where year like 84 it will find it.

I am sure there will be more to it when the coding begins, but santak, GP and myself I think we can figure it out.

 

[santak]

I know what I can do, if the years are 84-89, I can write up a for loop that will take the variable = 84, loop it and add 1 to it, till it become 89. Then, under the years field, with it being a text field in the database, would be listeds as 84 85 86 87 88 89 and if we did querry where year like 84 it will find it.

Just so that I understand your approach correct:
you want an input form, with a starting year and ending year for the part and then just loop between those two values and enter it into the DB....
Wouldn't it be better, instead of making the year field in the DB a varchar, to make it a tinyint, index it and enter the information in multiple rows. It'll blow up the DB a little, but I guess, it will be faster in the end, once you look up data.

 

[Sam Simpson]

yeah, but like you said, it will be more entries in the table.

With it being a text, it would be easier to make a single year searchable in a multiple year field, with the where like command.

But, you know PHP better than I do, so whatever you think is better. My first thought was how you described, a seperate entry for each year.

 

[santak]

the thing here is not PHP but more the design of the DB. A 'where like' query takes more time, than looking up an index integer.

For Example:
you enter the waterpump from above:

year	item	partnumber
84	water pump	mopar 123
85	water pump	mopar 123
86	water pump	mopar 123
87	water pump	mopar 123

when you index the year field, it'll build up another internal table, to look up the year and finds then all data entries with the year, say 85. And from these entries it'll sort out the water pump, that you looked up.
Now, if I want every part listed for one year, then I get this data faster this way, than browsing through all year fields via the 'where like' query. indexing int datatypes is faster and easier to do, than indexing varchar datatypes. At least from what I understood.

Again, this has nothing to do with php, this is all your database design. You can do it either way. I have no clue how big this is going to get or how much space you have left for the database, but my feeling is: the 'where like' query is a quick and dirty approach, that most of the DB designers I met so far try to avoid and rather sacrifice a little bit more space on the hard drive to gain speed.

 

[Sam Simpson]

Ok, I understand.

We will also have to do the same for engine sizes, and models. So one part could essentially have over 100 entries.

 

[santak]

Ok, I understand.

We will also have to do the same for engine sizes, and models. So one part could essentially have over 100 entries.

not necessarily, it depends if this is supposed to be an all Dodge or only Dodge Trucks 73-93 Database:

let's see, how many different engines are there? 6? 225 (or whatever that little 6 banger was), 318, 360, 383, 400, 440....anything else?
With the models it might get a little hairy, if there are substantial differences between the 4WD and 2WD models.

Otherwise, you might be able to do it the following way:
enter the engine sizes as fields and give them the value 1 or 0. That way, you don't have to enter each item 100 times and you can still find the result relatively quick.
As I said, I don't know a lot about the differences between D and W models and if there are major differences, I am sure, there are for some special parts.

Ok, just a little break now back from thinking:
how about you break the whole thing up in 2 or 3 different tables? A 4WD truck table, a 2WD truck table and a car table. If I want to look up a part for my 4WD truck, I don't have to wait for the DB to sort out all the other parts that are not even for a 4WD etc. Of course, to enter the information, you may need to update up to 3 tables. Might seem to be a little bit more work, but it really depends on what the final thing is supposed to be.

That's just my personal take on this issue, maybe somebody else wants to chim in and bring up another view. Personally, I would invest a lot of time on a good data base design and rather go the extra mile than having a hit and run thing now that cloggs up over the time and I would have to redo it.

 

[Sam Simpson]

but some parts it doesn't matter if it is 4wd or 2wd. for instance, a water pump for a 318 and 360 is the same from 72 to 93 (maybe to 88 only?) so that is about 40 entries. They work in any ton truck or RC. So 1/2 ton, 3/4 ton and 1 ton, truck, RC and trailduster. So that would be 3x40, then 3x120, right?

 

[santak]

So, can I conclude from the above, that we only care about 1/2 tons, 3/4 and 1 tons plus RC and TDs in different configurations?
Assuming that the TD and RC are the exact same thing in part numbers, this would add up to 4x2 fields in the DB (2WD and 4WD). Plus the 6 engines, so this is 14 fields, that will be filled with 0s or 1s.

example:

year	item	partnumber	318	360	440	D150	W150	RC4
84	water pump	mopar 123	1	1	0	1	1	1
85	water pump	mopar 123	1	1	0	1	1	1

etc.

So for the waterpump it would be 20 lines in the DB (given that it fits from 73-93).
If you split up the 4WDs and 2WDs, then it will be another table, with combined 40 lines in both tables, or, adding a 3rd table for cars, it would be 60 lines all together.

I guess you would need to test the speed of the query, once doing the 'where like' thing for the year, the model and the engine or by going to the right table and looking up the entry via the indexed integer value for the year and engine and model. Could be interesting, but my guess is, that if you add something like
84 85 86 87 | waterpump | D150 W150 D250 W250 D350 W350 RC TD | 318 360
it'll take more time to look it up once you add waterpumps for other models, engines and years.

Afterall, it comes down to small space or fast speed....or a good mix of both

 

[Sam Simpson]

ok, I get what you are talking about now with the on and off fields.

Now, do we really need things searchable by year? Or even by type of truck? I guess on some things we do, but others we don't.

Maybe to expand on what you are talking about, we could do the years with the on off deal too. What do you think? That would be smaller dbase but with the quicker style query, right?

for instance the fields for the years would be

72 73 74 75 76 77 78 79 80 81 etc

with either the 0 or 1 to denote if it is applicable for that year.