home 
wiki
wiki
Spelling: HardwareDatabase
The old Hardware Database [1] 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 [2] 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 [3]
* Devices such as the Avaya AP-3 [4] with dual slot architecture
make schema design more difficult than I had initially imagined --
TysonClugg [5]
* 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.
Comments welcome! -- Tom Fifield
-------------------------
Links:
------
[1] http://melbournewireless.org.au/?OldHardwareDatabase
[2] http://melbournewireless.org.au/?Hardware-Template
[3] http://melbournewireless.org.au/?TysonClugg
[4]
http://www.avaya.com/ac/common/index.jhtml?location=M1H1005G1015F2063P3153N5064
[5] http://melbournewireless.org.au/?TysonClugg
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]