Не фиксированный полей, а только поля с фиксированной длиной. Char/int — можно, varchar/longtext — нельзя и т.д…
В остальном — если речь о том, что Вам нужно вытаскивать определённые данные о пользователе, то вопрос в том — какие Вам данные о пользователе нужны? Может проще ввести в таблице пользователей поле типа text и аггрегированные данные (баланс там, очки, карма) хранить там? Вместо огорода с отдельными кэшами? Выборка из таблицы пользователей по ID будет не сильно медленнее чем кэши.
б) в общем и целом. до 30-40к у ноутов идет «меряние железом», проц, винт, порты, увидеть в том ценовом диапозоне хороший экран — редкость неимоверная (хороший не в плане крутой цвет IPS и углы такие что видно аж сзади, а проходящий стробоскопический тест, с хорошей контрастность и яркостью, матовый, без бликов). А вот от 40-50к уже можно и нужно выбирать хороший экран и не обращать внимание что у кого-то будет пара лишних мегагерц.
Не перепродаете, а оказываете услугу (можете назвать себя агентом клиента например по поиску хостинга, если удобнее, когда Вы платите в яндекс.директ — Вы без понятия кому он реально платит, так же как и клиент с Вами).
Перепродажа подразумевает, что получив от клиента 120р — Вы вычитаете из них 100р которые потратили и платите налог с 20р. А если Вы платите со 120р, то здесь по всем параметрам именно услуга.
Второй вариант, вспомнить что лицензия требуется только для оказания платных услуг. Если дописать в договор пункт о том, что телематические услуги клиентам на абонентке предоставляются бесплатно, то это опять же неплохой вариант для Вас.
ИБ для физиков у авангарда очень пристоен, по платежам и расшифровкам и информации — в чем-то даже превосходит альфу.
А вот что там для юриков — хотелось бы самим узнать.
* уточнение по 1. ID считают любой гос.документ с фио и фотографией. Студенческий — нет, права — да, загран — да, пенсионная карточка — нет (т.к. без фото), ну и далее по логике.
Пересчитывайте при включении объявлений данные по объявлениям конкретного пользователя, равно как и по другим событиям. Это не так часто будет происходить и объем данных невелик.
Дополнение: альфа без 2-ндфл заявку ни на кредит, ни на кредитную карту даже не примет.
Однако если являешься их клиентом по обычному счету (карте), то спустя некоторое количество пропущенных денег — могут предложить кредит/карту сами, что бы согласиться на это — 2-ндфл и прочего уже не понадобится.
Во всех cms которые я видел, продукты — это обычные элементы с определенным набором полей, а магазинный модуль — это корзина+оплата. Узкое место — именно организация бд товаров.
Опишите подробнее структуру и тип Вашей базы товаров. От нее все сильно зависит.
Говоря о счете за судебные издержки, не забывайте, что если оператор выиграет суд, то эти судебные издержки оплатит опять же абонент.
Срок исковой давности тут тоже не так однозначен, в плане даты с которой его считать. Если оператор считал абонента подключенным и списывал деньги, то как следствие он не видел проблемы, а следовательно и нарушения закона все это время. Фактически срок может отсчитываться с даты первого звонка о долге.
Главное не заостряйтесь на «лицензии на кредитование», т.к. никакой лицензии что бы вогнать абонента в минус не нужна абсолютно, но зато можете показать что Вы совсем не в теме, если с того конца провода вдруг окажется юрист:)
Проверяют редко — но могут проверить. Вам тут 999 человек из 1000 может сказать что «ничего не было», но Вас это сильно утешит если Вы будете одним из 1000 кого проверили и посадили?:)
У маковской нет некоторых привычных pc-шых клавиш, плюс по ней как-то пальцы скользили немного. Но низкопрофильность очень нравилась, поэтому искали максимально приближенный аналог.
Плюс к этой клаве идет в комплекте силиконовая накладка, что хорошо, если нет комплекса по поводу «пульт в полиэтилене», т.к. гигиена и защита от кофе.
И чисто программный способ — попробовать хранить данные в массиве или даже тупо конвертить в json строку. Данные-то чисто массивные, возможно оверхед происходит именно из-за использования объекта. В производительности можете слегка потерять, но если это откатит потребление памяти к прежним 2гб — возможно это того стоит.
В остальном — если речь о том, что Вам нужно вытаскивать определённые данные о пользователе, то вопрос в том — какие Вам данные о пользователе нужны? Может проще ввести в таблице пользователей поле типа text и аггрегированные данные (баланс там, очки, карма) хранить там? Вместо огорода с отдельными кэшами? Выборка из таблицы пользователей по ID будет не сильно медленнее чем кэши.