20251012

2025/10/12

Access

隠しオブジェクト

オブジェクトを「隠しオブジェクト」として設定すると、ナビゲーションウィンドウ上に表示されなくなる。

これにより「Accessを利用する人」にとって不要なものを隠すことができるため、誤操作を防げる。

ナビゲーションウィンドウの隠したいオブジェクトを右クリック → 「プロパティ」
属性の「隠しオブジェクト」にチェック

「Accessを設計する人」にとっては表示されないと困るので、ナビゲーションウィンドウの設定から隠しオブジェクトも表示されるようにできる。

ナビゲーションウィンドウの何もないところ右クリック → 「ナビゲーションオプション」
表示オプションの「隠しオブジェクトの表示」にチェック

隠しオブジェクトに設定されたオブジェクトは薄めの色で表示される。

参照整合性

リレーションを張ったテーブル間でデータの一貫性と整合性を保つ仕組み。

リレーションシップの種類（1対多または1対1）に応じて、それを満たさない操作は行えない。

フィールドの連鎖更新

主テーブル側で参照整合性に使用しているフィールドの更新を許可する。

更新した時、それを参照しているリレーションテーブル側のデータも更新される。

リレーションテーブル側で外部キーを変更するのは問題ない。（存在しない主キーへの参照は無理）

レコードの連鎖削除

主テーブルでリレーションのあるレコードの削除を許可する。

削除した場合、それを参照しているリレーションテーブル側のレコードも削除される。

リレーションテーブル側でレコードを削除するのは問題ない。

別のAccessファイルからのインポート

「外部データ」タブ →「新しいデータソース」→「データベースから」→「Access」
ファイルを選択し、「現在のデータベースに（略）をインポートする」にチェック
インポートするオブジェクトを選択して「OK」
「インポート操作の保存」をすると同じインポートを後で再実行できる。
「先頭行をフィールド名として使う」にチェック。
フィールドごとにオプション設定が可能。（インポートする/しない、データ型、フィールド名など）
「主キーを自動的に設定する」にチェック（既存のフィールドを主キーとすることも可能）
インポート後のテーブル名を指定し、「完了」

Excelファイルからのインポート

「外部データ」タブ →「新しいデータソース」→「ファイルから」→「Excel」
ファイルを選択し、「現在のデータベースの新しいテーブルにソースデータをインポートする」にチェック

インポートとリンク

「インポート」は別のデータソースのデータをコピーして取り込むことを指す。コピーなのでAccess上でデータを操作してもインポート元のデータソースには反映されない。

「リンク」は別のデータソースとデータに対して直接参照、操作できるように接続することを指す。Accessから行った操作はリンク先のデータソースにも反映される。

逆にリンク先のデータソースに操作があった場合はAccessを開き直すか、テーブルを再読み込みすることでAccess上に反映される。

エクスポート

データを別の形式でエクスポートできる。

エクスポートするオブジェクトを開く
「外部データ」タブ →「エクスポート」グループ → エクスポートする形式をクリック
ファイル名やレイアウト保持などの設定をし、「OK」

Next.js

動的ルートセグメント

https://nextjs.org/docs/app/api-reference/file-conventions/dynamic-routes

URLの一部の値（パスパラメータ）に応じてページを生成する仕組み。

URLごとに内容が異なるページを動的に生成できる。

App Routeでは、 app/blog/[slug]/page.tsx というように取得したいパスパラメータの箇所を [] 付きのディレクトリ名で表す。

layout.tsx 、 page.tsx 、 route.tsx では params 経由でパラメータを取得できる。

この値を元にAPIリクエストなどを行いページの生成を行う。

Next.js 15 から params が Promise型になったことに注意。これによって値を取得するには await が必要になった。

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params
  return <div>My Post: {slug}</div>
}

クライアントコンポーネントでパスパラメータを取得する場合は use フックや useParams フックを使用する。 useParams フックは引数を取らず、コンポーネントツリーのどこからでも取得できる。

'use client'
import { use } from 'react'
 
export default function BlogPostPage({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = use(params)
 
  return (
    <div>
      <p>{slug}</p>
    </div>
  )
}

ディレクトリ名を [...slug] というように ... をつけると、「キャッチオールセグメント」として定義できる。こうすると指定した位置以降のすべてのセグメントを配列として取得できる。

例）app/blog/[…slug]/page.tsxの場合

app/blog/a/ → {slug: [’a’]}
app/blog/a/b/c → {slug: [’a’, ’b’, ’c’]}

さらにキャッチオールセグメントの括弧を [[...slug]] というように二重にすることで、そのセグメントを任意にできる。（パラメータのないルートもマッチする）

例）app/blog/[[…slug]]/page.tsxの場合

app/blog/ → {slug: undefined}
app/blog/a/ → {slug: [’a’]}
app/blog/a/b/c → {slug: [’a’, ’b’, ’c’]}

動的ルートセグメントのページをビルド時に生成したい場合は、生成したいパスパラメータを generateStaticParams で返すようにする。

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())
 
  return posts.map((post) => ({
    slug: post.slug,
  }))
}

generateStaticParams() から返されたパラメータを元にページが生成される。

内部的に generateStaticParams() 内のfetchは重複排除される。これによって、複数ページで同じ fetch を行っている場合のリクエストを削減できる。

JavaScript

date-fns

日時操作を扱うライブラリ。

JavaScript標準のDateは扱いづらく読みづらい。

date-fnsでは日付の加減算、比較、フォーマットなどの操作を分かりやすく扱えるようにやっている。

タイムゾーンについてはDate同様、実行環境のローカル設定に依存する。

fns は functions の略で、操作は全て関数モジュールとして提供される。そのためツリーシェイキングやコードスプリッティングとの相性もいい。

date-fns-tz

date-fnsでタイムゾーンを扱うための拡張ライブラリ。

IANAタイムゾーン（Asia/Tokyoなど）を指定した操作が可能になる。

内部的には依然としてDateを扱うのでちょっとわかりづらいところがある。（使い方を間違えると二重変換してしまう場合がある）

// ↓これは正しい
const formatted = formatInTimeZone(new Date(), 'Asia/Tokyo', 'yyyy/MM/dd');

// ↓これも正しい
const jst = utcToZonedTime(new Date(), 'Asia/Tokyo');
const formatetd = format(jst, 'yyyy/MM/dd'); // date-fnsの関数

// ↓これだと二重変換になってしまう
const jst = utcToZonedTime(new Date(), 'Asia/Tokyo');
const formatted = formatInTimeZone(jst, 'Asia/Tokyo', 'yyyy/MM/dd');

Temporal

Experimental段階のJavaScript標準API。

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal

Date の欠点を解消すべく作られた日付操作APIで、タイムゾーン対応やイミュータブルな操作が可能になる。

標準化されれば date-fns や date-fns-tz が不要になるかもしれない。

ブログ

Notionに記録していたメモを勉強も兼ねて microCMS + Next.js 環境に移行
https://blog-one-ruddy-51.vercel.app/blog/