Здесь один единственный PK на таблице, данных лишних вообще нет — такая работать будет быстро на весьма внушительных объёмах. 1 лям — это вообще ни о чём.
Потом запросто партицируется по user_id.
По спичкам:
добавлять столбец не нужно, зачем? Придётся индекс раздувать или иначе — вообще данные с диска поднимать, вместо работы только по PK. Совершенно бесполезные манипуляции.
Хранить же прочитанные или только непрочитанные — зависит от пользователей, какая их часть активно читает уведомления. Обычно активных пользователей меньше и тупо компактнее хранить прочитанные.
GamePad64, какие тормоза, о чём вы? Без разгона шины память вообще с головой упирается в FSB. Оттого на LGA775 и фактически никакой разницы между DDR2-800 и DDR3-1333.
Мизерная разница (5-10% даже от DDR3-1866) достигается только за счёт снижения латентности.
0) Аптайм по определению от количества ядер не зависит. И не является безразмерной величиной.
Вероятно, вы всё-таки про уровень LA. LA = 3 — вполне нормальное значение.
1) От того, то база на другой машине, совершенно не следует, что вы в неё не упираетесь.
2) не думать надо, а знать. Машина у вас под рукой, хоть банальные top и iostat можно посмотреть.
> для предотвращения возможного нанесения вреда железу
Железу пофиг. Может файловая система обидеться. Ну и потеря не сохранённой работы.
> есть же софт для ИБП, который автоматически выключает?
Если есть COM-порт или USB — то есть софтовая поддержка. Иначе в этих интерфейсах смысла нет, только дороже делают.
Другой вопрос, что софт может быть отвратным. Я для одного упса реверсил протокол обмена и писал нормальный автовыключатель, вместо предложенного поделия на яве.
Формально, я не достиг дао ООП и под объектом в контексте синглтона понимаю именно конструктор и деструктор.
Говоря конкретно о PHP, статичные классы, в отличии от синглтона, не умеют __get, __set, обращение к необъявленным членам приводит вовсе к fatal error, что может накладывать определённые неудобства, если захочется динамично обращаться к членам.
xel:
0) обнако, в случае необходимости активных действий с этим значением — весьма рационально сделать дополнительное поле. MySQL не умеет индексы по вычисляемым значениям.
1) триггер не может обновлять текущую таблицу
Ну если такие коробки под диски — машинка априори очень мало места занимать не будет. mITX всего на пару см. шире 5" отсека. Я-то думал, речь о 2,5" дисках, раз о таких размерах думаете.
Положить плату горизонтально, над ней подвесить 4 такие коробки вертикально с, где-то, 8-10мм просветом — вполне изящный ящичек.
Или вертикально коробки, сбоку от них закрепить плату.
По своему опыту проектирования корпуса скажу — сделайте габаритные муляжи основной комплектухи из какого-нибудь картона да покрутите в руках. Или в софте 3d моделирования, если это ближе.
Потом запросто партицируется по user_id.
По спичкам:
добавлять столбец не нужно, зачем? Придётся индекс раздувать или иначе — вообще данные с диска поднимать, вместо работы только по PK. Совершенно бесполезные манипуляции.
Хранить же прочитанные или только непрочитанные — зависит от пользователей, какая их часть активно читает уведомления. Обычно активных пользователей меньше и тупо компактнее хранить прочитанные.