да всё равно сколько кода не мне же его писать:-) самое главное звучание и возможность сыграть на обычной клавиатуре без миди — к примеру было бы очень круто если бы клавиши
от «y» до "]" — были до ре ми фа соль ля си — первой октавы
соответственно:
«7» — до диез
«8» — ре диез
«0» — фа диез
"-" — соль диез
"=" — ля диез
ну и от «z» до «m» — до ре ми фа соль ля си малой октавы
«s» — до диез
«d» — ре диез
«g» — фа диез
«h» — соль диез
«j» — ля диез
а если ещё будет возможность задавать октавы (повышать понижать другими клавишами — то вообще жесть:-)
что-то я размечтался — захотелось сыграть что-то на обычной клавиатуре как на настоящем пианино — наверное надо самому этим занятся
Кстати сейчас ребёнок до 10ти лет уже может прыгнуть с парашютом в тандеме (то есть пристёгнутый к инструктору) — то есть на ребёнке нет никакой ответственности — ему требуется только испытывать ощущения и впечатления — а всё за него выполняет инструктор. Прыгать можно лет с семи. Свободное падение испытанное до 10 лет может сильно повлиять на ребёнка, но важно что бы он сам этого захотел, потому что иначе — испытает сильный страх и может замкнуться в себе.
Это не я подразумеваю а автор статьи, протестую я только потому что при нашей культуре и отношению к собственной планете — не хватало ещё свалку в космосе устраивать ведь всем ясно что просто выбросить мусор в космическое окно значительно дешевле чем построить безопасный мусоропровод к солнцу. Давайте не гадить в космосе, не потому что от этого мы скоро умрём или ещё произойдёт какой-то катаклизм — а просто потому что гадить это скверно. И начинать гадить в космических планетарных и межпланетарных масштабах не стоит.
Хорошо, продолжаем, итак у нас есть две первые таблицы country и country_history — в таблице country будет содержаться первая часть телефонного номера: код страны.
Теперь добавим ещё одну таблицу и назовём её secondary_telephone_code — эта таблица будет содержать вторую часть нашего телефонного номера, а сам значимый текстовый код может быть как кодом населённого пункта так и кодом мобильного оператора. В этой таблице связка полей country_id и code будет уникальной (я сейчас не говорю о том как прописывать первичные ключи — а просто указываю на логику таблицы). То есть по сути ваша таблица locality_code превращается в secondary_telephone_code только она теперь напрямую связана с country. Также в таблицу secondary_telephone_code помимо полей country_id и code — можно добавить поле type или typeId — которое будет указывать на то чем именно является этот код — кодом города? мобильного оператора? или ещё чем-нибудь? а также необязательное поле text — в котором можно хранить любое примечание к коду (название города мобильного оператора или что-то ещё).
Обращаю ваше внимание что type и text не являются обязательным полями (как минимум для начала функционирования системы телефонных номеров).
Также, на данном этапе, пока у нас ещё нет адреса — нам не надо выстраивать связи между таблицей secondary_telephone_code и например таблицами region или другими. То есть выстроить связи в будущем мы сможем — но наши основные связи не поменяются и для логики хранения и изменения телефонных номеров такая сущность как регион не играет никакой роли (не путаем с логикой выбора или вноса информации пользователем/оператором). Название таблицы secondary_telephone_code — может показаться не самым благозвучным — но оно действительно удачное — потому что эта таблица содержит в себе именно то что означает её название вторую часть телефонного кода (можно добавить в название part и превратить таблицу в secondary_part_telephone_code — а можно этого и не делать). То что эта вторая часть может быть кодом города и выбираться из списка после выбора страны и региона, либо кодом оператора — не имеет никакого значения на этапе проектирования структуры телефонного номера.
По аналогии с country_history — мы создаём таблицу secondary_telephone_code_history
Итак у нас есть 4 таблицы — две основные и две для хранения истории изменений основных таблиц.
Добавляем третью основную таблицу phone — как у вас на схеме — и связываем её с таблицей secondary_telephone_code — всё структура данных системы телефонных номеров готова. В ней можно хранить реальные номера телефонов и отслеживать изменения, например если данные поступают из внешних источников. Конечно же, для того, что бы привязать эту структуру к интерфейсу вноса и редактирования информации — её необходимо доработать, и связать с другими подсистемами (адресом, операторами связи и прочими) — но с нашей задачей, хранить в себе любые телефонные номера мира и отслеживать изменения кодов стран городов и мобильных операторов — данная структура справляется. и не содержит ничего лишнего.
Теперь предлагаю вам поставить следующую задачу, исходя из того что у нас уже есть, если вы согласны с тем что мы получили и для чего мы это получили, и того чего вы хотите от системы на следующем шаге. Чем меньше будет шаг тем лучше.
Да, спасибо, но мне самому не надо ничего доказывать — то что я был на МАКСЕ и видел там Мрию я точно помню, мог ошибиться с годом, но теперь точно не ошибся потому что в следующем году её уже разобрали, а МАКС в 93м был первый. Товарищ выше какой-то провокатор, возможно намерено путающий нумерацию, как в фильме Top Gun, где F-14 сражались с «Миг-28».
Прекрасно, вы сами себя опровергли вот взгляните на Руслан ru.wikipedia.org/wiki/%D0%90%D0%BD-124 у него 4 двигателя 4! А у Мрии 6.
(Если бы вы не нашли это фото мне бы пришлось ехать к маме с папой и сканировать слайдовые фотографии тех времён).
от «y» до "]" — были до ре ми фа соль ля си — первой октавы
соответственно:
«7» — до диез
«8» — ре диез
«0» — фа диез
"-" — соль диез
"=" — ля диез
ну и от «z» до «m» — до ре ми фа соль ля си малой октавы
«s» — до диез
«d» — ре диез
«g» — фа диез
«h» — соль диез
«j» — ля диез
а если ещё будет возможность задавать октавы (повышать понижать другими клавишами — то вообще жесть:-)
что-то я размечтался — захотелось сыграть что-то на обычной клавиатуре как на настоящем пианино — наверное надо самому этим занятся
Или что бы вообще клавиши соответствовали обычной клавиатуре?
есть конечно споры писал ли Бах ХТК именно под этот строй или под строй Веркмейстера но факт что с 18-го века используется именно этот строй.
Теперь добавим ещё одну таблицу и назовём её secondary_telephone_code — эта таблица будет содержать вторую часть нашего телефонного номера, а сам значимый текстовый код может быть как кодом населённого пункта так и кодом мобильного оператора. В этой таблице связка полей country_id и code будет уникальной (я сейчас не говорю о том как прописывать первичные ключи — а просто указываю на логику таблицы). То есть по сути ваша таблица locality_code превращается в secondary_telephone_code только она теперь напрямую связана с country. Также в таблицу secondary_telephone_code помимо полей country_id и code — можно добавить поле type или typeId — которое будет указывать на то чем именно является этот код — кодом города? мобильного оператора? или ещё чем-нибудь? а также необязательное поле text — в котором можно хранить любое примечание к коду (название города мобильного оператора или что-то ещё).
Обращаю ваше внимание что type и text не являются обязательным полями (как минимум для начала функционирования системы телефонных номеров).
Также, на данном этапе, пока у нас ещё нет адреса — нам не надо выстраивать связи между таблицей secondary_telephone_code и например таблицами region или другими. То есть выстроить связи в будущем мы сможем — но наши основные связи не поменяются и для логики хранения и изменения телефонных номеров такая сущность как регион не играет никакой роли (не путаем с логикой выбора или вноса информации пользователем/оператором). Название таблицы secondary_telephone_code — может показаться не самым благозвучным — но оно действительно удачное — потому что эта таблица содержит в себе именно то что означает её название вторую часть телефонного кода (можно добавить в название part и превратить таблицу в secondary_part_telephone_code — а можно этого и не делать). То что эта вторая часть может быть кодом города и выбираться из списка после выбора страны и региона, либо кодом оператора — не имеет никакого значения на этапе проектирования структуры телефонного номера.
По аналогии с country_history — мы создаём таблицу secondary_telephone_code_history
Итак у нас есть 4 таблицы — две основные и две для хранения истории изменений основных таблиц.
Добавляем третью основную таблицу phone — как у вас на схеме — и связываем её с таблицей secondary_telephone_code — всё структура данных системы телефонных номеров готова. В ней можно хранить реальные номера телефонов и отслеживать изменения, например если данные поступают из внешних источников. Конечно же, для того, что бы привязать эту структуру к интерфейсу вноса и редактирования информации — её необходимо доработать, и связать с другими подсистемами (адресом, операторами связи и прочими) — но с нашей задачей, хранить в себе любые телефонные номера мира и отслеживать изменения кодов стран городов и мобильных операторов — данная структура справляется. и не содержит ничего лишнего.
Теперь предлагаю вам поставить следующую задачу, исходя из того что у нас уже есть, если вы согласны с тем что мы получили и для чего мы это получили, и того чего вы хотите от системы на следующем шаге. Чем меньше будет шаг тем лучше.
Относитесь к минусу проще, а сами пользуйтесь им реже.
(Если бы вы не нашли это фото мне бы пришлось ехать к маме с папой и сканировать слайдовые фотографии тех времён).