The [OldHardwareDatabase old Hardware Database] was hopeless at helping people find a device based on a set of criteria.  We need a database type application that is able to store all relevant details about various pieces of hardware in an easy to manage (but technically correct) fashion.



Lets start by defining a database schema to store information about various wireless devices.  If you know about how wireless devices are put together and know a little about database design, then please help by contributing to the schema design and discussion.



For the time being use this [Hardware-Template] to create wiki pages for hardware your reviewing. Just switch to edit mode on the page and copy the 

content to the clipboard, then paste it into a new page.



----



!! TABLES

!!! Hardware

*device 

generation (ie 802.11b/g/c) Secondary Primary Key

manufacturer

chipset

antenna_connector

comments

rx_sens

tx_pwr

FOREIGN KEY generation REFERENCES TABLE Generation

FOREIGN KEY manufacturer REFERENCES TABLE Manufacturer

FOREIGN KEY chipset REFERENCES TABLE Chipset



!!! Manufacturer

*manufacturer

website

comments



!!! Chipset

*chipset

generation

manufacturer

driver_location_1

driver_location_2

comments

FOREIGN KEY manufacturer REFERENCES TABLE Manufacturer

FOREIGN KEY generation REFERENCES TABLE Generation





!!! Generation

*802.11?

frequency

TX_RX_speed_1

TX_RX_speed_2

TX_RX_speed_3

TX_RX_speed_4

max_txpower

comments



!!! gen-device-table

*device

*supported_generation

FOREIGN KEY device REFERENCES TABLE Hardware

FOREIGN KEY supported_generation REFERENCES TABLE Generation



!!! connection_type

*device

*type (usb/pci/eth/firewire)

FOREIGN KEY device REFERENCES TABLE Hardware



!!! OS_support

*device

*OS

FOREIGN KEY device REFERENCES TABLE Hardware



!!! same as

*manufacturer

*device



(* = primary key)



!! Discussion

* There are lots of potential flaws in the schema as it stands -- TysonClugg

* Devices such as the (http://www.avaya.com/ac/common/index.jhtml?location=M1H1005G1015F2063P3153N5064 Avaya AP-3) with dual slot architecture make schema design more difficult than I had initially imagined -- TysonClugg

* Maybe just use the "features/comments" field in the Hardware table to put something in about the more exotic stuff. Or it might be reasonable to increase the number of fields for the various 802.11x flavours. I can't see there being hardware that would support more than 2 standards at the moment, so perhaps have a main mode and a secondary and add a "modes/standards" table that we can easily add new standards to.

* Supported_OS might be a bit ambitious, I can think of 4 without going into the various windows/mac flavours, trying to keep it simple.

* for devices that support multiple standards (ie the Avaya AP3) we could have multiple entries for the same device, just with a secondary primary key (generation) that differentiates between the 2, can you do that? This does introduce redundant information though.

* I'm getting my head around many to many relationships. So far this is a bit simplistic. -- Matt

* Didn't notice a field for model code / marketing code eg dlink 900ap or 900ap - Peter

* The hardware schema does not allow for someone wanting to buy / sell an antenna. -- Andrew L



I think it would work better by abstracting the 'radio' from hardware.

This way we can support : plain cards(just a radio entry), router units (hardware with potentially multiple radios, removable cards), and non-radio devices like antennas.



{http://www.melbournewireless.org.au/~tfifield/Hardwaredb.jpg HardwareDB}



Comments welcome! -- Tom Fifield



----