Обитателите на стаи 1-6 са вързани към рутер 1 и ако отидат в стая 10 нямат връзка с рутер 2, а сигналът от рутеер 1 е много слаб (т.е. пак нямат връзка).

Нещо не разбрах - искаш или не искаш да правиш "handover"? http://en.wikipedia.org/wiki/Handover

MAC филтрирането е абсолютно ненадеждно. По-добре забрави за него.

Тези рутери имат ли настройки за ползване на RADIUS сървър? Би било доста по-добро решение.

Код

GeSHi (SQL):
CREATE TABLE `country` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `name` char(25) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UQ_record` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8
 
CREATE TABLE `province` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `country_id` int(10) UNSIGNED DEFAULT NULL,
  `name` char(25) NOT NULL,
  `EKATTE` char(3) NOT NULL,
  `EKATTE_code` char(5) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UQ_record` (`country_id`,`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=29 DEFAULT CHARSET=utf8
 
CREATE TABLE `municipality` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `province_id` int(10) UNSIGNED DEFAULT NULL,
  `name` char(25) NOT NULL,
  `EKATTE` char(5) NOT NULL,
  `EKATTE_code` char(5) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UQ_record` (`province_id`,`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=265 DEFAULT CHARSET=utf8
 
CREATE TABLE `city` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `municipality_id` int(10) UNSIGNED DEFAULT NULL,
  `name` char(25) NOT NULL,
  `type` char(4) NOT NULL,
  `zip` char(4) DEFAULT NULL,
  `atitude` smallint(5) UNSIGNED NOT NULL,
  `latitude` float(10,7) DEFAULT NULL,
  `longitude` float(10,7) DEFAULT NULL,
  `population` bigint(20) UNSIGNED DEFAULT NULL,
  `EKATTE` char(8) NOT NULL,
  `EKATTE_code` char(5) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UQ_record` (`municipality_id`,`name`,`type`) USING BTREE,
  KEY `IX_EKATTE` (`EKATTE`),
  KEY `IX_zip` (`zip`),
  KEY `IX_name` (`name`),
  CONSTRAINT `FK_municipality_id` FOREIGN KEY (`municipality_id`) REFERENCES `municipality` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5303 DEFAULT CHARSET=utf8
 
 

Хм ... сега видях, че не съм създал foreign-keys constraint-ите за всички таблици

PS: Явно това е по-стара версия (като гледам съм я ползвал за експорт) - има разни тъпизми от сорта на "type varchar(4)" а то си е smallint

Само да добавя, че при големи ДБ идеята да се пускат още услуги на машината не е добра. Стигне ли се до swapping ... жална ти майка

Можем да спорим до безкрайност. Тъй като аз самия доста съм проектирал бази работещи с високо натоварване, досега нормализираните са били винаги по-ефективни.

Не споря  - изказвам мнение 

Със сигурност не мога да твърдя, че съм работил кой знае колко с много големи бази данни. Реално, може бе 2-3 пъти. В единия случай беше за callcenter с около 120'000 записа на ден (100 агента "пишещи" и към 20 teamleader-и/supervisori-и четящи) само за обажданията. Това ми е и най-голямата база май - Postgre SQL

В началото, дизайнът на ДБ винаги го правя в най-нормализиран вариант. След това, ако се появят проблеми може и да има някаква денормализация или изнасяне на "offline" view-та за преглед в не реално време.

http://en.wikipedia.org/wiki/Denormalization

In computing, denormalization is the process of attempting to optimise the read performance of a database by adding redundant data or by grouping data.[1][2] In some cases, denormalisation helps cover up the inefficiencies inherent in relational database software. A relational normalised database imposes a heavy access load over physical storage of data even if it is well tuned for high performance.

Нещо не можах да разбера какво точно показваш. Би ли опитал да се използваш моя пример?

Говоря за нещо такова:
http://en.wikipedia.org/wiki/Data_warehouse#Normalized_versus_dimensional_approach_for_storage_of_data

Нормализираните бази винаги са по-бързи от денормализираните. Защо иначе ще се прави нормализация?

Не бих казал, че винаги е така ... Понякога е нужно да се направи денормализация за целите на анализ - най-често срещания пример е "последно състояние". Пример за който се сещам в момента (и е възможно да се прави със субселект) е състояние (сегмент) на "call" в callcenter - в опашката, поет от оператор, пренасочен от оператор и т.н. При една силно нормализирана база данни би трябвало да се пазят само записи (many-to-many, Call<->State) по отношение на състояние + дата/час. Но този начин на работа прави заявките за анализ (репорти) доста бавнички - има търсене на запис с най-голяма стойност на дата/час колоната. Най-простото решение е да се добави колона "последно състояние" към Call таблицата, което си е чиста проба денормализация.

Аз не казах

Човек, няма начин да определиш размера на (всички) базата в GB, която ще "върви" на дадена машина.
Например, ако базата е силно денормализирана, малко на браой таблици и връзки между тях (подготвена за репорти и анализ), то тогава най-вероятно ще можеш да обработваш бързо повече информация. Ако обаче базата е нормализирана с голям брой таблици и връзки между тях, то тогава нещата стоят по съвсем различен начин. Да не говорим за конкурентност на връзките, LOCK и т.н.

Това ми се струва прекалено общ въпрос за да може да се отговори еднозначно... Все пак дизайнът (а от там и заявките) на базите данни оказва огромно влияние (индекси, join-ове и т.н.)

Да, наистина въпроса и прекалено общ, но задаващия го, няма опит с въпросната база и за това пита, какви са възможностите на този хардуер за максимално голяма база, за да си направи сметка за кое колко място да отдели при разделянето на харда.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

jet ти е отговорил вече

Но слънцето е право - много зависи от какво и как.

Все едно слушам жена ми  

Това ми се струва прекалено общ въпрос за да може да се отговори еднозначно... Все пак дизайнът (а от там и заявките) на базите данни оказва огромно влияние (индекси, join-ове и т.н.)

Netbeans IDE ? Доволен съм от него.

[_]

Това _ мембър функция ли е?
Май нещо за поддръжка на различни езици.

От тук:

$this->view->headTitle($this->view->translation->_('MAIN_PAGE_TITLE'));

Напълно нормално име за метод Може би имаш предвид че функцията _() е alias на gettext()? Точно поради сходната функционалност ползвам _ за име на функцията.

А иначе за имена на функции и променливи ...

Код

GeSHi (PHP):
<?php
 
 
function КралиМарко()
{
	echo "Hello world!";
}
 
КралиМарко();