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

----